I'm planning on taking a crack at a Serialization template library and I'm looking for feed back. My thinking so far is up on my blog here:

http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-1-of-n.html

Please comment! (here or there, doesn't matter, I think I'll see both)

On Wed, 20 May 2009 15:43:16 +1200, BCS <none@anon.com> wrote:

> I'm planning on taking a crack at a Serialization template library and I'm looking for feed back. My thinking so far is up on my blog here:
>
> http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-1-of-n.html
>
> Please comment! (here or there, doesn't matter, I think I'll see both)
>
>


Have you thought about making a OODB so have the full oo programming with data and functions but the objects can be saved and retrieved in a transactional way?

Hello Tim,

> On Wed, 20 May 2009 15:43:16 +1200, BCS <none@anon.com> wrote:
> 
>> I'm planning on taking a crack at a Serialization template library
>> and  I'm looking for feed back. My thinking so far is up on my blog
>> here:
>> 
>> http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part
>> -1-of-n.html
>> 
>> Please comment! (here or there, doesn't matter, I think I'll see
>> both)
>> 
> Have you thought about making a OODB so have the full oo programming
> with  data and functions but the objects can be saved and retrieved in
> a  transactional way?
> 

The target usage is to stuff data structures into file or network streams. Eventually, I'd like to build a web services lib from this that can serve proxy an interface with very little code:

/////common:

interface I { ... }
interface J { ... }

/////Server side

class CI : I { ... }
class CJ : J { ... }

auto server = new Server();

server.Serve!(I)(new CI(), 8080); //proxy that object on port 8080
server.Serve!(J)({return new CJ;}, 8081); // create a objects to proxy on port 8081

server.start();

//// client side

I i = new Proxy!(I)("somehost.net", 8080);
J j = new Proxy!(J)("somehost.net", 8081);

(moved from .announce to dm.D)

BCS wrote:
> I'm planning on taking a crack at a Serialization template library and I'm looking for feed back. My thinking so far is up on my blog here:
> 
> http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-1-of-n.html
> 
> 
> Please comment! (here or there, doesn't matter, I think I'll see both)
> 

I strongly suggest figuring out early how you want to support multiple serialization formats.  From experience, it's deceptively difficult to splice that into the design later.

As for invocation, consider making the deserialization a constructor.  I assume that in the example that the Deserialize method was static and acts as a factory?

Another point for you to ponder... do you want to support builtin types as a top level serialization point.  ie, can you serialize a single int or must it be a struct or class or aggregate?  If you _do_ want to support it, consider what will happen for formats that don't support it, such as xml and json.

I agree with the limitations you've listed, but it does restrict the scope of data structures that can be serialized (or at least successfully round-tripped and remain in-tact).

Later,
Brad

Hello Brad,

> (moved from .announce to dm.D)
> 
> BCS wrote:
> 
>> I'm planning on taking a crack at a Serialization template library
>> and I'm looking for feed back. My thinking so far is up on my blog
>> here:
>> 
>> http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part
>> -1-of-n.html
>> 
>> Please comment! (here or there, doesn't matter, I think I'll see
>> both)
>> 
> I strongly suggest figuring out early how you want to support multiple
> serialization formats.  From experience, it's deceptively difficult to
> splice that into the design later.
> 

I'm already puzzling over that one <g>

> As for invocation, consider making the deserialization a constructor.

The problem with making it a constructor is that it dosn't match with structs.

> I assume that in the example that the Deserialize method was static
> and acts as a factory?

yes. 

> Another point for you to ponder... do you want to support builtin
> types as a top level serialization point.  ie, can you serialize a
> single int or must it be a struct or class or aggregate?  If you _do_
> want to support it, consider what will happen for formats that don't
> support it, such as xml and json.

I was thinking it would end up as a string wrapped in a tag (for XML):

<int>42</int>

It turned out that the first pass was easy. No unexpected problems. However I noticed a few more things I'm going to have to deal with at some point.

http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-2-of-n.html

Again, please comment! (here or there, doesn't matter, I think I'll see both)

p.s. Sorry, no code yet (it's still messy) but fixing that is on the list as well.

Now with Code!

http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-3-of-n-with.html

BCS wrote:

> I'm planning on taking a crack at a Serialization template library and I'm looking for feed back. My thinking so far is up on my blog here:
> 
>
http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-1-of-n.html
> 
> Please comment! (here or there, doesn't matter, I think I'll see both)

A question:
Should every object contain "mixin Serializable!()" in its declaration?
It is easy to add this in own classes, but not easy to 3rd-party libraries.
for instance: tango


--Qian

On Tue, 26 May 2009 13:29:39 +0400, Qian Xu <quian.xu@stud.tu-ilmenau.de> wrote:

> BCS wrote:
>
>> I'm planning on taking a crack at a Serialization template library and I'm
>> looking for feed back. My thinking so far is up on my blog here:
>>
>>
> http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-1-of-n.html
>>
>> Please comment! (here or there, doesn't matter, I think I'll see both)
>
> A question:
> Should every object contain "mixin Serializable!()" in its declaration?
> It is easy to add this in own classes, but not easy to 3rd-party libraries.
> for instance: tango
>
>
> --Qian
>

Good serialization library supports external serialization via template specialization (or similar tricks) :)

BCS pisze:
> I'm planning on taking a crack at a Serialization template library and I'm looking for feed back. My thinking so far is up on my blog here:
> 
> http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-1-of-n.html 
> 
> 
> Please comment! (here or there, doesn't matter, I think I'll see both)
> 
> 

Hello!

I would like to mention that serialization library for D already exists:

http://www.dsource.org/projects/doost

It supports most of common requirements for serialization library:
- easy to use API
- most built-in types and user defined types (UDT) are already serializable
- out of class serialization
- versioning of UDT; importing old versions to new versions
- thread/exception safe (well... AFAIK :-) )
- large unit test suite
- configurable serialization backend (archive): JSon, Binary, SimpleText
- serialization of classes with user defined constructors

I don't want to discourage you from implementing your own library, but on the other hand you may consider contributing to this, already existing library. It took me few months to get where it is right now, so it is really a LOT of work; Unfortunately I don't have time to develop it further right now...

There are still few things which should be implemented:
- serialization from base class (difficult, when we don't want to demand additional coding work from user)
- Tango support (should be relatively easy)
- XML archive support (foundation framework already there)
- serialization for complex types
- cleanups, improvements, porting to D 2.0
- better documentation

If you would be interested just drop me an e-mail:

aarti -at- interia -dot- pl

I am very open to suggestions and changes :-)

Best Regards
Marcin Kuszczak
(aarti_pl)