Re: [boost] Serialization Mailing list

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2002-12-11 18:48:10

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.

********************original message**********************

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

>     * 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.

>     * 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?

>     * 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.  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.  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.

>5. Well, Item 3 drifted a bit into technical issues, so here's a
>   more-comprehensive list of technical issues I'd like to see
>   considered carefully and collaboratively.  

Unfortunately, I haven't had the time to dig into the technical
details.  I'll continue to watch the discussion and comment when I
feel
that I understand the issues.

Cheers-
Augustus

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com