Re: [boost] Serialization Mailing list

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
>> formats?
>
> 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.

Good.

>>     * What kinds of applications are we explicitly NOT intending to
>> serve?
>
> A couple of people have mentioned that we're not trying to make a
> database.  

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