From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-16 02:54:30
>>1. Will you mind if anybody writes a 'describe' based wrapper and
> 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.
>>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)
> xml_archive ==> // converts to/from xml text
> basic_archive =>
> std::streams ==>
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk