[boost] [Property Tree]Problem domain

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-23 16:19:39

Hi,

When I my review I never thought it will cause any long discussion. It's all 
very clear in my little corner. I must admit that my understanding 
significantly changed since. But my main point remains the same. I do not 
have time to reply to all the related messages. 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. How could you tell whether one interface/implementation is better 
than another without understanding how it's planned to be used?

   Now, based on library docs, we could try to give it some educated guess. 
Unfortunately this lead me to decide that this library is not acceptable in 
none of the potential problem domains.
Don't get me wrong. The library could be used by some users. But the same is 
true for almost any one. But my criteria for library acceptance is really 
simple: library should be usable for most users in problem domain. "Some" 
users doesn't cut it.

So let's see.

Option 1:
Library to support program runtime parameters originated in different 
sources
=================

>From my standpoint library is missing several crucial features to qualify in 
this domain.
  a) No decent CLA parser
  b) No conflict resolution.
      If your parameter coming from different sources it's obvious that at 
some point you need to decide which parameter to prevail: one from config 
file or one from CLA.
  c) No automated validations
      Configuration even more then any other human input require strict 
validation (more because it's frequently produced by third parties - not 
library designers. That includes end-users, operation department remote 
library user etc). We need some notion of "schema" support.
   d) No automated processing/notification.
      Many application prefer to build their runtime parameter support as 
event driven system. No support for this is presented.

And these are just major deficiencies.

Option 2:
Library for permanent storage of application configuration that does not 
have to be human editable .
==================

My primary objection in this domain is that an alternative better solution 
exist. I would use Serialization library and save/load directly C++ objects. 
As for the "non human editable" clause,
IMO if you decide to present a way for the user to edit configuration 
through application, no need to support also editing using some external 
means. If you need some of the parameter to be externally editable (but not 
from within application) - use separate storage for them.

Option 3:
Generic facility to manipulate hieratical data with permanent storage 
support.
==========================

My main objection in this domain is that author decided that his particular 
data structure would be good enough for all usages. The word "particular" is 
main offender here.  I don't believe any "particular" data structure would 
be good enough. Some novice users may use simple structure with class Leaf 
and class Brunch. Some prefer generic tree one. Some need compile time 
polymorphism only. Some could use runtime one. Some Would use boost::variant 
as value.
  IMO save/load side of the library like this would need to be made to work 
with any data structure satisfying some concept. The same applies to access 
methods (This is the reason why you need to switch to free function based 
interfaces)

Option 4:
Facility to manipulate hieratical application configuration that have to be 
human editable and application writable at the same time.
=======================

First of all I need to remark that this domain is kind of limited (and 
internally conflicting IMO - I don't see why you need configuration editable 
both ways). This option struggle from the same problem as option 3 - 
hardcoded in-memory presentation. Also I believe that this domain also 
require for loaders/savers to keep original formatting and/or comments.  On 
the other hand This library doesn't need CLA/registry support in this case. 
While it's config files support should be more flexible.

Author need to decide which option match his understanding. But IMO library 
in this current form isn't acceptable in any of them.

Regards,

Gennadiy