Re: [boost] [Boost Review] Property Tree Library

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-22 09:22:10

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message 
news:e2c2s5$l3n$1_at_sea.gmane.org...
: > In case of tracking-ids I just wanted them out, because I do not have
: > duplicate objects in human-created files. On the other hand, I 
couldn't
: > disable tracking per-class, because I still wanted other archives to 
do
: > tracking on these objects. A couple of days ago I even posted a 
question
: > for Robert, and he says that I would need to create my own version of
: > tracking.hpp.
: >
: > So as you can see it is not all roses with serialization library and 
human
: > readable files.
:
: Well you need to bring it all to the Robert attention. Boost 
serialization
: should support wide variety of archives, including simple xml.

But can it?
Can boost::serialization support an archive format that:
 - is easily human-readable, human-editable, and human-*writable*
    (which IMO excludes having "class ID" fields and such)
 - provides straightforward support for default values and optional 
fields,
   which is important for backwards compatiblity with older archives
 - will not bark at additional/not-understood fields that are present
   in the file (important for forward-compatibility)
 - provides support for archives that are read/written by other
   programming languages (as JSON does).

By the current support for XML provided by boost::s11n, I doubt
that these features can be easily provided.
But I'd love to be proven wrong.
Can you help us see the light ?

I find you are being quite vocal against a library which obviously
does not address a need that you have.  But as Bjarne himself likes
to admit, no one knows what most C++ programmers do.

When I define a configuration or data file, I like to design it
around what end-users will think is logical, not around the (current
and possibly changing) representation of the data within my C++
program.  Boost::s11n as it is today does not seem to support this
approach. ptree does much better.
And others have other reasons to like ptree.

The fact that, for your needs, ptree doesn't allow anything that s11n
doesn't already do, should NOT be a reason to reject the library.

As I wrote elsewhere, regex and spirit are just as overlapping
as ptree and s11n.  Yet many needs are only served well by
one of the two twin libraries.

Regards,
Ivan
-- 
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form