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

From: Alexander (al_at_[hidden])
Date: 2006-04-23 10:19:27

I am participating at project at which similar system was "invented".
And so could provide some suggestions concerning the problem.

We start our project from necessity to create windows registry like system
for value storage at hierarchical order. Windows approach was quite adequate
for our tasks but desire of compatibility makes it impossible to use it.
After all win registry interface is archaic and inconvenient. It was our
start point.

We implemented interface which use node, leaf and attribute approach because
of win registry influence. Now I could say that it's looks like mistake.
This multilevel model makes interface too complicated without any benefits
at reality. So, homogeneous interface of Property Tree Library is much more
elegant and simple.

I think that one tree implementation is not enough for all kinds of task.
The simplest tree of course could be useful for small tasks. But it is not
adequate for really big projects. So we create proxy which hides from us
details of realization. It gives me opportunity to make unexpected solution
for GUI. I don't like GUI programming and try to avoid it if only possible.
So I create solution which allows users modify registry at safe manner.
Methods of input, validators, access policy and so on prevents user from
unsafe input. Safe behavior is based on attributes which stored at the same
registry. But it's unsafe and inefficient to store data and visualization
attributes at the same place. So proxy which mixed two different proxies for
benefits of visualization was created.

We decide that symbol '/' is forbidden for using as name. (If you wish to
store filename or something which contains '/' you could store it as data
not as key. Or if it so necessary to have '/' at name it is possible to use
"//" mechanism. Point is not better at all because it's also could be at
filename. 'Point looks strange as separator at hierarchical systems. Once
more I prefer '/' after win registry semantic. Specifying separator at every
function is ugly solution. )

For saving and loading we also use parser mechanism. But we have the basic
class for it. It's my favorite trick to use vector of parsers for saving and
loading.

About name. Property Tree Library is not bad name I think, because being
familiar with such approach I immediately understood what it's about.

>What is your evaluation of the design?
At least, the separator problem should be resolved adequately.
>What is your evaluation of the implementation?
>What is your evaluation of the documentation?
Good enough
>What is your evaluation of the potential usefulness of the library?
I'm not quite sure but author do not positioning library as registry. I
think this road should be leading to registry. At current form it is bonded
to quite simple systems.
>Did you try to use the library? With what compiler? no
>Did you have any problems? no
>How much effort did you put into your evaluation?
It was only the comparison with my current solution. But it's taking a long
time to.
>Are you knowledgeable about the problem domain? Yes

The Boost library at my opinion should resolve problem at full scale. It
should provide foundation for full variety of different applications from
small ini files to multithreaded and even dispersed registries. Alas, at
current design library couldn't help me. But bear in mind that I am rather
centered on my existing design and that library resolve more simple case I
should vote for addition library to boost. 

Regards,
Alexander Belyakov

P.S.
Well, I want make it clear to prevent misunderstanding that this library is
not overlapped by boost.serialization at all but it will be overlapped by
boost.registry if some one proposed it. It's clear enough for me that this
library shouldn't be viewed as XML reader or any other reader. It's nice
library with elegant and simple interface.
Author defines property tree as a recursive data structure at another place
he wrote it's a container. And it is really so. But REGESTRY is CONCEPTION
not data structure. SERIALIZATION is also CONCEPTION. Author makes a lot of
work. And he makes it almost ready to transform interface of container to
something more interesting - to interface of conception. His library useful
and I couldn't ask him to make a lot of work more. But if he wants he could
make from it something more powerful.

I could provide more information about my project if it's interesting.