From: David Abrahams (dave_at_[hidden])
Date: 2002-12-13 21:21:31
Augustus Saunders <infinite_8_monkey_at_[hidden]> writes:
> Ok, at Dave's request I'm reposting here, and I'll continue to post
> both places until we see if the other list gains any momentum.
The other list is disabled.
>>2. Careful description of scope. Answer questions like:
>> * Is this a persistence or serialization library?
> Or more to the point, what kind of library do we want to make? I
> would like to see both eventually. I think people were expecting
> serialization, and it is IMO the more accessible of the two.
Which definition are we using <.002 wink>?
>> * Is it important to be able to plug in arbitrary archive
> I don't think it would be useful (if possible) to support *arbitrary*
> formats. The target should be a wide swath of common format
> paradigms. If somebody needs a format that doesn't fit well within
> one of our format categories, then this library just plain won't be of
> much help.
If there's a postprocessing step, you can probably support arbitrary
formats. Maybe that's silly though: there's probably no point in
putting that step in the library.
>> * Is it important to be able to use the same UDT serialization
>> code to write several different archive formats?
> I appologize; I'm not up on my acronyms. UDT?
User Defined Type.
>> * What kinds of applications are we intending to serve?
> I think the primary uses for serialization will be save files, inter-
> application data transfer, and network transfers. I think part of the
> point of a serialization library is to make it easier for an
> application with lots of classes to serialize to multiple formats.
That's an important point. Not agreeing or disagreeing; I just wanted
to highlight it.
> Code maintenance should be of utmost concern. Adding, removing, and
> changing formats applied over thousands of classes should be
> facilitated to whatever extent is possible.
>> * What kinds of applications are we explicitly NOT intending to
> A couple of people have mentioned that we're not trying to make a
What, exactly, does this mean?
> I concur, but when we do tackle a persistence library, it must be
> able to serve as a front end to an OODB. In other words, while we
> don't want to try and write a database, it should be possible for a
> database writer to use a boost::persistence library as a replacement
> for some of the custom preprocessor tools they use now to map
> database <==> runtime objects. At any rate, that is not the library
> I think we should tackle first.
Does "make a database" equate with "persistence" in your mind?
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk