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

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2006-04-25 12:25:59

This is my second review of the library
(I mistakenly reviewed rev4 before).

Since Marcin plans to change the get/set interface
of the library it would be better to arrange
review for rev6, within reasonable time interval
(few months, not in a year). I would be happy
with current acceptance as well,
as futher improvement are very likely.

The library has potential to be very useful
for real world application (in current form
and even more in rev6).

Clearly, domain for the library is to read/write
configuration data, not to serve as generic tree
or complete XML parser.

Temptation to extend the now simple API into
giant does-it-all tool may result in something
practically no one would dare to use.

I do not see the overlap with PO as obstacle.
Merge between PT and PO is unlikely - I have
never seen anything like this on Boost so far.

Things that need improvement:
------------------------------------------

1. Examples, examples, examples.

    Adding many small but complete examples
    into documentation is the most effective way
    how to increase acceptance of the library
    among users. No one is interested
    in reading lenghty manual just to get a value
    from INI.

   If the documentation is already too big drop
   reference, heck, drop anything but add examples.

   As others had pointed, there is more to improve
   in the documentation.

2. Limitation of the library should be clearly spelled,
    especially for XML. I am in favour to limit XML features
    as much as possible - it is not task of simple
    configuration tool to provide validating parser
    and whatnot.

    Rename te library to "simple property tree"
    if people cannot stop requesting more.

    Existence of ptree is no barrier for anyone to
    create "powerfull property tree".

3. Others:

* basic_string should not be hardcoded.
  There are too many string implementations floating
  around.
* Optional MT safety may be added.
* Named template parameters may be used to deal
  with large number of traits
* Preserving comments and whitespace in INI/JSON/INFO
   could be the /most/ important reason someone
   decides to use the library.
* The library should be able to read multiline data
   that do not require backslash at the end. It would be
   usefuul e.g. to store scipts inside configuration.
* The comand line parser should have reference to PO
   and should clearly state its limits.
* It is possible and useful to extend the registry parser 
(registry_ptree?).

One existing registry library can be found on:
http://synesis.com.au/software/stlsoft/help/group__winstl__reg__library.html

* The property tree itself may be serializable
  as it could be part of larger application state
  (this is different from using Serialization as
  engine for PT).
* Support for various Unicode encodings
  (frex reading UTF16 BE and
   converting the strings to ANSI, all transparently).
* Overloads for parsers to parse given memory block
  (e.g. mapped file, shared memory)
* An user defined datatype (e.g. boost::any) attached
  to each node may be useful when one is content
  with the ptree data structure and doesn't want to move
  it from/to C++ structures.

Features that I do not consider as needed:
---------------------------------------------------------
* Transformation from one format to another.
   Unless this capability is naturally present
   in the library the tool should not get more
   complicated because of it.
* Validators, type safety checkers, notifiers etc.
  Usefulness for the 80% of real world applications is
  IMHO the main selling point and I am far from sure
  whether these features could be implemented
  without sacrifying current simplicity.
* Genericity for sake of genericity.
  Purpose of the lib is to read configuration
  data with least of hassle and then get out of way.
  It is not Boost.Tree (and should not be documented as if it is),
  it is not Visitor, it is not in memory database.
* I would be very cautious with replacing parts of the
  library with Serialization / Multi-index.
  There are many practical consideraration
  - compilation time, supported compilers,
  projects with multiple executables, versioning.
  People using the library just want it to work
  and would not be willing to solve possible
  problems related to other libraries or even
  debug through 3pp libraries.
* Breaking library to parts. This is just a way
  to tell intended users: "you'd better to quickly
  hack up something by hand, don't bother with PT".

/Pavel