Re: [boost] [Property Tree]Problem domain

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-30 03:46:24

"Marcin Kalicinski" <kalita_at_[hidden]> wrote in message
news:e2h11e$659$1_at_sea.gmane.org...
[...]

> *** The goals ***
> ===========================
>
> 1. Allow efficient and intuitive manipulation of hierarchical,
> human-readable data structures in memory.

I am not sure what you mean but human-readable (do you plan to read bits in
a memory like a book?;o),
but this looks like quite a generic goal. Usually such a goal require a
generic component to match. The one you present doesn't match this task.

> Like a DOM, but with as simple to use interface as possible!

 I believe interfaces could be made simpler if you would limit scope of the
tree usage.

> The interface must leverage C++ strengths (type safety, templates to
> automatically convert types), and maybe more importantly C++ idioms (ptree
> = std container, iterators, algorithms). Tradeoffs: no stress on
> performance,

Why do you think it's an acceptable tradeoff for generic hierarchical data
structure? Also as one of the goal you stated "efficient". Doesn't this look
like internal contradiction? std containers doesn't exhibit this tradeoff.

> no following of W3C DOM standard.

There are reasons people write standards. Among them are portability - any
application that expect DOM interface wouldn't be able to use your tree, and
recorded experience - people thought about proper interfaces - why not
follow them?. If you target "Like DOM" data structure - why not follow
standard?

> 2. A facility to load and save most popular, human readable data file
> formats (and present them in the form of above structure). Tradeoffs: no
> stress on supporting each format in its entirety. Omit less used and more
> complicated parts of the file formats. Get it working for 80% of cases
> now, rather than for 100% never.

> I believe the library meets the above goals reasonably well at the moment.
> With all the proposals I got I think I can make it do it even better.

As of now your library doesn't support format preservation and comments.
isn't it?

> *** Problem domain ***
> ==========================
>
> First of all, I don't think author of almost any library can definitely
> say: this library will be used to do A and B, but not C. Loading human
> readable data, allowing its manipulation in memory, and saving it back
> again. This can be used for a plethora of things, and nobody cannot
> possibly be expected to enumerate all of them. I will try to present a
> sample:
>
> 1. Loading and saving program data. For example in a GUI editor for
> something that is persisted in an XML format with externally defined
> layout. Cannot use boost::serialization, because it isn't format-flexible.
> You get your XML out of it if you really want, but only in vanilla
> flavor. No saying what should go where.

What registry parser/loader doing in your library then? Do you expect users
to edit registry manually? If not Serialization library should be able to
deal with this task better.

> 2. Serialization (in primitive form, but supports human-editable formats).
> I say "primitive", because I'm now an initiate - I used
> boost::serialization in some of my projects. Before I did that, I would
> say ptree offered "adequate" serialization facilities.

By serialization we usually mean C++ objects <-> permanent storage
conversion. You library presents some kind of intermediate state. I am not
sure it qualifies to be named like this. But that's is minor point.

> 3. Loading of program options, aka program_options overlap

What CLA parsing doing here? You couldn't save it back. It's rarely
hierarchical. Your parser doesn't do anything one expect from reasonable CLA
parser. I don't see this as problem domain for you.

> 4. Passing of data between parts of the same program. This is a little
> more tricky than the others. For example, consider the parts to be (1) a
> fancy menu system for a video game, and (2) the game itself. Menus build a
> ptree and pass it to the game. Why? You can save the generated ptree and
> reuse it later without starting the menus. You can hand-edit it and
> configure the game without having the menus at all. This is extremely 
> handy
> if menus and game are developed separately. You may find yourself in a
> situation where you are working on the game, but menus do not exist yet in
> an usable state. You do not need to "fake" a menu system to test your
> game. You just handcraft the ptrees. (i.e write some text files in your
> fav format).

At the beginning I only need load part. Later I wont need human readability 
support (actually i believe it would be even dangerous). I don't see that as 
a good example. I personally doesn't find ptree tradeoffs needed. I would 
write menu in C++ directly at the beginning and then switched to 
serialization lib. In general I believe this domain is artificial.

> 5. A use that surfaced lately: target for boost::serialization
> (ptree_archive). Why? Can save archives to all formats supported by ptree,
> effectively extending boost::serialization for free. And (speculating),
> maybe it can be used to automatically reorganize XML layout, so that
> comments on boost::serialization in #1 no longer apply.

This is not currently part of the library, so may not be considered to be in 
it's domain. In a future we may discuss it.

> 6. Translation from one format to another.

This is natural part of 2

Gennadiy