Re: [boost] Serialization Mailing list

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2002-12-16 18:57:05

David Abrahams wrote:
>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.

In a pedantic sense, I think given any non-lossy serialization S and
complete meta-information M, it would be possible to define T(S,M)
such that S' = T(S,M) yields some arbitrary format.  So, given S, S',
and M, is it possible to computationally infer T?  Otherwise, you
might as well postprocess S yourself.  I suppose we could facilitate
that by allowing a serializer object to accept a post-processing
functor.  This seems a little far fetched, but who knows.

>Does "make a database" equate with "persistence" in your mind?

No.  Once you have a good persistance library though, it starts
making sense to build a database of persisted objects.  You use a
database back end instead of a serial back end when you need fast
store/load, fast searching, and all the other reasons you ever use a
DB over a flat file.

You could, however, persist to a serial archive and use that as some
kind of save file; you could even make that archive some kind of XML
so a human can read and modify it.  Once you're using the persistance
front end, though, you can (ideally) "upgrade" to a database backend
transparently.  Kind of like you can use an ODBC interface to a text
file, and then upgrade to a "real" DB as your needs grow.

Before, I've had save files generated with a serialization framework
that reached its limits.  I wished I could transistion to a DB, but
the hit for re-architecting the app was too expensive.  Our intent
was to save and restore app state; we didn't care that it was
serial--we had very different formats for serial network protocols. 
In that case, we got stuck with bad limitations--very large text
files that had to be completely deserialized into memory (creating
in-memory objects for everything), and then searching those in-memory
objects for what we needed.

>From a software eng perspective, I see serialization as a trap.  It
has lots of historical precedant (a good chunk of that from MFC), so
people just kind of assume that it's the way to go for everything. 
Boost, however, is forward looking, and I see this as an opportunity
to escape the trap.  Serialization and persistance have different use
cases and purposes.  Most applications would have BOTH in my
byte-stream utopia: persistance with a DB backend for local storage,
and serialization to a variety of formats for data exchange with
other applications or users.

It's confusing because you can serialize and persist to an identical
archive.  Same observable results.  Same ends, different means.  It's
a one way confusion, though: you'd never use a persistence framework
when you need to serialize to some random format.

Hope this helps.  Cheers-
Augustus

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