I am just asking that. Although serialization is not a common technique,
I am interested in having one in D.
:-D
-- 
School, yet another nickname for anonymous.
:D ;-D

Do you mean serialization of classes, or serialization of threads? If the former, then I may be able to help you out. If you meant the latter, then read on:

It appears as though Java 1.5 is adopting the full embrace of Doug Lea's asynchronous package. Well, at least it looks like Doug's stuff. His home page is over here:  http://gee.cs.oswego.edu/dl/

It would be uber-cool if someone were to port even part of Doug's impressive synchronization and serialization library over to D ...

- Kris

"School" <school@users.sf.net> wrote in message news:c5b9tf$s3t$1@digitaldaemon.com...
> I am just asking that. Although serialization is not a common technique,
> I am interested in having one in D.
> :-D
> --
> School, yet another nickname for anonymous.
> :D ;-D

Kris 提到:
> Do you mean serialization of classes, or serialization of threads? If the former, then I may be able to help you out. If you meant the latter, then read on:
> 
> It appears as though Java 1.5 is adopting the full embrace of Doug Lea's asynchronous package. Well, at least it looks like Doug's stuff. His home page is over here:  http://gee.cs.oswego.edu/dl/
> 
> It would be uber-cool if someone were to port even part of Doug's impressive synchronization and serialization library over to D ...
> 
> - Kris
> 
> "School" <school@users.sf.net> wrote in message news:c5b9tf$s3t$1@digitaldaemon.com...
> 
>>I am just asking that. Although serialization is not a common technique,
>>I am interested in having one in D.
>>:-D
>>--
>>School, yet another nickname for anonymous.
>>:D ;-D
> 
> 
> 
I actually mean serialization of classes.
Thank you.

-- 
School, yet another nickname for anonymous.
:D ;-D

Dsc.io can handle that kind of thing quite well, with help from the developer. For each "serializable" class you implement the ISerializable interface (two method: read & write), and then use one of the Reader/Writer derivatives to thaw/freeze the contents of said class (CompositeReader and CompositeWriter are a good choice for this kind of thing, possibly in conjunction with the Endian classes).

That is, Dsc eschews the Java approach of "serialization through introspection" in favour of a framework to get the job done under the watchful eye of a developer. There's no rocket science involved here; in fact, you could do this kind of thing with printf and scanf if you really wanted to <g>

Naturally, this approach only serializes the 'data' portion of a class; not the code portion! Dsc.server will eventually use this stuff internally to maintain (optimized) state across a load-balanced cluster.

- Kris


"School" <school@users.sf.net> wrote in message news:c5d8on$pfv$1@digitaldaemon.com...
> Kris ´£¨ì:
> > Do you mean serialization of classes, or serialization of threads? If
the
> > former, then I may be able to help you out. If you meant the latter,
then
> > read on:
> >
> > It appears as though Java 1.5 is adopting the full embrace of Doug Lea's asynchronous package. Well, at least it looks like Doug's stuff. His
home
> > page is over here:  http://gee.cs.oswego.edu/dl/
> >
> > It would be uber-cool if someone were to port even part of Doug's
impressive
> > synchronization and serialization library over to D ...
> >
> > - Kris
> >
> > "School" <school@users.sf.net> wrote in message news:c5b9tf$s3t$1@digitaldaemon.com...
> >
> >>I am just asking that. Although serialization is not a common technique,
> >>I am interested in having one in D.
> >>:-D
> >>--
> >>School, yet another nickname for anonymous.
> >>:D ;-D
> >
> >
> >
> I actually mean serialization of classes.
> Thank you.
>
> --
> School, yet another nickname for anonymous.
> :D ;-D

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c5c2fd$20p7$1@digitaldaemon.com...
> Do you mean serialization of classes, or serialization of threads? If the former, then I may be able to help you out. If you meant the latter, then read on:
>
> It appears as though Java 1.5 is adopting the full embrace of Doug Lea's asynchronous package. Well, at least it looks like Doug's stuff. His home page is over here:  http://gee.cs.oswego.edu/dl/
>
> It would be uber-cool if someone were to port even part of Doug's
impressive
> synchronization and serialization library over to D ...
>
> - Kris

It does look like a nice package, and best of all, it's explicitly public domain. This means it can be transferred to D without worries (except for the two classes that carry a Sun copyright).

Anyone want to take the lead on this?

School wrote:
> I am just asking that. Although serialization is not a common technique,
> I am interested in having one in D.
> :-D

To give Kris's Dsc a run for its money (sorry Kris...) I've added
an experimental serialization support to std.stream at

http://home.comcast.net/~benhinkle/stream.d

Comments welcome. Here's an example of how to use it:

module mymodule;
import std.stream;

// Sample serializable class
class Foo : Serializable
{
  int some_field;          // sample field
  void write(Stream s)
  {
    s.write(some_field);   // write out object state
  }
  static Object read(Stream s, char[] id)
  {
    Foo obj = new Foo();
    s.read(obj.some_field);
    return obj;
  }
  const char[] sID = "mymodule.Foo 1"; // verison 1 of mymodule.Foo
  char[] serializationID() {return sID;}
}

static this()
{
  registerDeserializeFcn(Foo.sID, &Foo.read);
  // can register other handlers for past versions if any...
}

int
main()
{
    // let's write out an instance of Foo
    File f = new File("test.txt",FileMode.Out);
    Foo o=new Foo();
    o.some_field = 42;
    f.write(o);
    f.close();

    // let's try to read in what we wrote
    f = new File("test.txt",FileMode.In);
    Foo p = (Foo)f.read();
    printf("p = %p, some_field = %d\n",p,p.some_field);
    return 0;
}

Ben Hinkle wrote:

> School wrote:
>
>> I am just asking that. Although serialization is not a common technique,
>> I am interested in having one in D.
>> :-D
>
>
> To give Kris's Dsc a run for its money (sorry Kris...) I've added
> an experimental serialization support to std.stream at
>
> http://home.comcast.net/~benhinkle/stream.d
>
> Comments welcome. Here's an example of how to use it:
>
What about when objects are serialized twice?   IMHO, in these cases you should link to one object. Something like this:

//write pseudo
if object already serialized (for this session) then //hint - use a map
 only write it's ID
else
 write ID and object

//read pseudo
if object already built then
   assign object from the map of built objects
else
   read and create object


-- 
-Anderson: http://badmama.com.au/~anderson/

On Tue, 13 Apr 2004 09:13:03 +0800, J Anderson <REMOVEanderson@badmama.com.au> wrote:

>Ben Hinkle wrote:
>
>> School wrote:
>>
>>> I am just asking that. Although serialization is not a common technique,
>>> I am interested in having one in D.
>>> :-D
>>
>>
>> To give Kris's Dsc a run for its money (sorry Kris...) I've added an experimental serialization support to std.stream at
>>
>> http://home.comcast.net/~benhinkle/stream.d
>>
>> Comments welcome. Here's an example of how to use it:
>>
>What about when objects are serialized twice?   IMHO, in these cases you should link to one object. Something like this:
>
>//write pseudo
>if object already serialized (for this session) then //hint - use a map
>  only write it's ID
>else
>  write ID and object
>
>//read pseudo
>if object already built then
>    assign object from the map of built objects
>else
>    read and create object

Hmm. maybe. I thought about that briefly but decided against it since
1) it adds complexity
2) there are probably several caching strategies that could be used
3) it can be implemented on top of basic serialization
4) D doesn't have weak references (AFAIK) so no deserialized object
   could be garbage collected until the map of built objects is
   cleared.

If an object or class (or classes) wants to cache then they have to cooperate. There is no default serialization implementation like in Java so user classes have to explicitly decide what they want to do.

For example (assuming casting to interfaces is not evil...)
class Foo
{
 Object x,y; // assume x and y always refer to the same object
 void write(Stream s)
 {
   s.write(cast(Serializable)x); // ignore null for simplicity
 }
 static Object read(Stream s, char[] id)
 {
  Foo obj = new Foo();
  obj.x = s.read();
  obj.y = x;
  return obj;
 }
}

yesterday i've independently coded a serialization lib... though its probably
ugly it may come to be useful in the struggle to create sth better :)
readme included.

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c5fdg4$1k5v$1@digitaldaemon.com...
> To give Kris's Dsc a run for its money (sorry Kris...) I've added an experimental serialization support to std.stream at

Nice one Ben!

Dsc registration is similar, but it registers the Object itself rather than a delegate/id pair. While I'm completely paranoid about allocating memory on a request-by-request basis within a server (Dsc.server allocates *zero* memory per request), I don't care a hoot about instantiating a living Object for registration purposes :-)

Likewise, Dsc does nothing further than provide a framework for serialization. Over time it will gain all sorts of nifty distributed caching mechanisms, that one can leverage the hell out of for high-performance clustered environments. However, in such an environment one should not be tossing Object-trees around the place (yeehaw!); so Dsc will not "encourage" such behavior with cool mechanisms for doing just that.

That's not to say there's not a need for serializing Object forests ... it's just not the focus for Dsc, and its a tough nut to crack whereby you can satisfy everyone.

- Kris