Boost logo

Boost :

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.


>> * 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] *
Boost support, enhancements, training, and commercial distribution

Boost list run by bdawes at, gregod at, cpdaniel at, john at