Re: [boost] Re: Re: Serialization library - submission #5 and request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-16 02:54:30

Robert,

>>1. Will you mind if anybody writes a 'describe' based wrapper and 
>>submits it.
> 
> 
> Of course anyone can submit something that builds on the serialization
> library.  Heck, the serialization library builds on all sorts of other boost 
> stuff.  I may not have interest in such a facility myself but I certainly
> don't insist that no one else have interest.

Excellent.

>>2. Will you be willing to tweak your library if 'describe' 
>>implementation will not be 100% orthogonal. I think there might be some 
>>problems with making both describe and save/load work.
> 
> 
> I would hope that describe would be 100% orthogonal.  If not, then it
> would have to be looked at.  In general I would not see any problem
> where the library is "too strong" in that in imposes unnecessary
> requirement.  I have gone to great efforts to avoid this from happening.
> Factoring our archive.hpp and stl.hpp were the result of exactly this
> kind of problem.  It made the "serialization" part much smaller and
> permited it to be more open ended.
> 
> Its interesting to note that an almost identical situation has arisen
> already.  In trying to find a general solution to exception safety
> I created demo_shared_ptr.cpp.  I came to believe that to 
> implement serialization of shared_ptr (a very, very, compelling concept)
> I needed access to a private member of shared_count.  I contacted
> Peter Dimov about this but I havn't been able to convince him to change  it.
> So for now I've just left it as an example in the serialization package.
> Naturally I hope to convince him to change his mind in the future 
> (if and when serialization gets added to boost) . If the libraries are well designed,
> this kind of thing will happen only occasionally and it should not be
> a long term problem.

I hope you'll describe this issue in more detail during formal review. 
Serializing shared_ptr is important.

> So basically, I have no objections to tweaking the library to permit
> it to be used more widely.  Note this is quite different to adding
> features that I believe should be maintained separatly.  Of course
> this is easier to agree upon this in the abstract ratther than
> specifica cases but all in all I consider
> myself a pretty easy going and reasonable person and would
> derive great satisfaction in seeing the library used a building
> block for unforseen applications.  I already see it as useful
> implementing Remote Procedure Call argument passing.
> 
> 
>>If yes, then I withdraw the 'describe' issue.
> 
> I would call the above a 'yes' mostly.

Ok, we agree then.

>>XML format would require member names, and this is another issue which 
>>will require support from your library.
> 
> 
> Now on the the real topic that interests me as it relates to "Describe"
> 
> I see the following future for serialization.  Read ==> as "implemented with"
> 
> XML export/import ==>
> 	C++ reflection ("Describe") ==> // associates names/variables
> 		boost 1.29
> 		?
> 	serialization ==>  // "flattens and unflattens" structures"
> 		boost 1.29 ( type_traites, etc)
> 		stl
> 	xml_archive ==>   // converts to/from xml text
> 		basic_archive =>
> 			stl
> 			std::streams ==>
> 				std::steambuf
> 
> 
> So that is where I see things fitting.  This is pure speculation, please don't ask
> me to defend this now.To summarize, "Describe" is really too important,  interesting
> and intricate to be shoehorned into serialization. It really deserves
> its own module/library.
> 
> Variable names required for XML would end up as part of C++ Reflection ("Describe").  

But won't we need to pass variable names to xml_archive?

> I am still thinking through the issue of global vs archive registration
> and I expect I will have more to say about this later.

I'm looking forward to your further comments.

- Volodya