Re: [boost] [Property Tree]Problem domain

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-23 19:02:03

>[...] So let me give it another try to convey my point clearly: I don't see 
>any reason to discuss library interfaces and even more implementation 
>without clearly stated problem domain.

I admit that the documentation fails to specify the problem domain. The 
tutorial presents the library as a config-file reader and stops there. Hence 
the original discussion, whether it overlaps 1:1 with program options or 
serialization, etc. Its my fault, I will try to correct this unpleasant 
state of matters.

> How could you tell whether one interface/implementation is better than 
> another without understanding how it's planned to be used?

*** The goals ***
===========================

1. Allow efficient and intuitive manipulation of hierarchical, 
human-readable data structures in memory. Like a DOM, but with as simple to 
use interface as possible! The interface must leverage C++ strenghts (type 
safety, templates to automatically convert types), and maybe more importanly 
C++ idioms (ptree = std container, iterators, algorithms). Tradeoffs: no 
stress on performance, no following of W3C DOM 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.

*** 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 flavour. No 
saying what should go where.

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.

3. Loading of program options, aka program_options overlap

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 wihout 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).

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.

6. Translation from one format to another.

I'm sure others could extend that list.

Best regards,
Marcin