"Marcin Kalicinski" <kalita@poczta.onet.pl> wrote in message news:e2h11e$659$1@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