Re: [boost] Overlap of property_trees with other boost libraries

From: David Abrahams (dave_at_[hidden])
Date: 2006-04-23 10:07:28

Ben Artin <macdev_at_[hidden]> writes:

> So, here is one way that I see to resolve the property_trees conundrum:
>
> 1) A library providing an in-memory property tree abstraction should be 
> submitted.
>
> 2) A library providing serialization of property trees to some common 
> configuration file formats should be submitted. This could be part of the same 
> library as in part 1. As part of this work, serialization library may need to be 
> modified to allow for archive formats that cannot represent the full range of 
> object and class tracking metadata.
>
> 3) Ideally, this should result in the ability to serialize arbitrary C++ objects 
> directly to a configuration file format -- in-memory data shouldn't have to be 
> in the explicit form of a property tree in order to be serializable to a 
> configuration file.
>
> 4) Property tree file formats should be allowed as inputs to the program options 
> library (and the existing program options configuration file format should be 
> subsumed by the library from part 2 above).

This might be the best approach in the long run.  However, IMO:

a. It's unlikely to happen unless this library is accepted into Boost,
   because it requires too much coordination among libraries with too
   much speculation: the serialization and program options authors are
   unlikely to have time to rework their libraries to support another
   library that *might*, someday, be accepted.

b. It shouldn't be a prerequisite for inclusion.  

Primarily, we review and accept *interfaces* and *documentation*, and
only secondarily the implementation details.  Once accepted, a
library's implementation can be, and often is, changed.

I'm not coming out in favor of or against acceptance (I haven't looked
at the library in enough detail yet), but IMO we should be asking
ourselves whether it has the right interfaces for a library in its
domain.  If we like the interfaces, and the implementation gets the
job done, we should accept.  Otherwise, ... reject.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com