Augustus Saunders <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
