|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-21 11:12:12
> : I admit I must've misinterpret the problem domain you are trying to
> cover.
> : So now you are saying that your library should be used to implement
> : permanent data storage? But we already have a solution for that either.
> : Much better IMO in any sense (safety, convenience, automation etc). All
> in
> : all in between PO an Serialization library I do not see any place for
> this
> : submission.
>
> Hi Gennadiy,
>
> There is a profusion of applications that use xml, JSON, or a similar
> format for data storage. In all these applications, being able to
> dynamically manipulate an in-memory representation of the data
> structure is a very common need.
> boost::serialize goes straight from C++ object to stream, and there
> is no opportunity to manipulate the stored data in-memory (let me
> be corrected if I am wrong).
See my other post. What do you mean by manipulate the data? Care to give an
example?
> : It's doesn't stand a comparison as runtime parameters support
> : facility even with PO library ( no conflict resolution, no formats
> : specification, no automatic/custom validation no async action assignment
> : etc). And it's doesn't stand a comparison as a permanent storage
> facility
> : with Serialization library (in most senses). Make no mistake these are
> two
> : different domains.
>
> xml, JSON, the Windows registry, some uses of command-line parameters, etc
> have a lot of common. And ptree seeks to provide a common in-memory
> representation for all these formats. I see a real value it in.
Runtime parameters support facility require a lot more then just common
representation. It needs to support at least following features:
* Conflict resolution
What if the same parameter is in multiple sources?
* Parsers should be flexible t osupport variety of formats
CLA parser in particular.
* There should be an ability for validation/notification automation.
I want to register a callbacks for particular parameters and validation
rules.
There are more, but my point is that this library doesn't address any of it.
So it couldn't be considered as viable candidate for runtime parameters
support
Also such facility wouldn't require any kind of fast search - no need to
complicate the design.
> But I have a question for you, or for any advanced user/developer
> of boost serialize:
>
> How would you look at ptree being a possible target format (Archive)
> for boost::serialize ?
I am not sure I understand: how PT could be an Archive? Archive if I am not
mistaken is the model of permanent storage. PT is the model of in-memory
storage.
Gennadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk