From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-22 23:46:14
Date: Fri, 22 Nov 2002 16:34:46 -0800 (PST)
From: Augustus Saunders <infinite_8_monkey_at_[hidden]>
>Persistence: A transformation-less transfer of application native
>data to an alternate storage medium. Only useful and only intended
>to be useful to applications that apriori agree on object type and
>layout, presumably by sharing headers. May optionally account for
>differences in architecture or compiler. Must be symmetric--support
>both store and load. Alternate storage formats would only differ for
>effeciency reasons, perhaps at the expense of not supporting
>constructs not needed by a given application.
>Serialization: A transformation of application native data into a
>serial intermediate exchange format specified by the application
>writer. Whether objects can be read back in an order different than
>they were stored, or if there is any object identification of any
>kind, is up to each individual format. Because it is not presumed
>that applications share apriori knowledge, it may be necessary to
>include meta-data regarding data types.
I edited out alot of the message that expanded upon these
I think the distinction is important. But actually I think the definitions
should interchanged !!!
The goals of the serialization library are clearly stated in the first part
of the documentation. Basically it is to be able to convert
of any arbitrary structure of data created by a C++ program into a string
of bytes and back again. I called this "Serialization" to distinguish it from
other data storage methods that have a diffferent purpose.
I didn't try to define Persistence as I see it as a more general notion.
Other data storate/recovery methods have different focus. e.g. Database
systems support a relational algebra accross multiple platforms
and languages. Other things are considered important such as transactional
integrity, security, logging and rollback, etc that are not of interest
in this context.
XML, as I understand its motavation, attempts to package data along with
its metadata in a more general way to promote portability across different applications.
No logically transparent system can address all of these situtations. They conflict
in fundamental ways. Of course, it can be proved that "all data is equivalent" in
some sense, but in the sense that we use it an think about it its not equivalent.
We impose a structure to think about it operators to manipulate it in accordance
with a larger purpose.
The archives used for serialization ar really small bridges to the i/o system. Attempts
to make them something they are not can only lead to a system which lacks
elegance and simplicity and is hard to use for its intended purpose.
I realize that the system as presented can benefit from some improvements.
But, as far as I know, there is no system which addresses so comprehensively the question
of Serialization (as I have used it). I could find no such system. Certainly none
has been submitted has been submitted to boost. That's why I wrote this one.
I was strongly influenced by my experience with Microsoft MFC. It was
a basically a good and useful system with a fair number of short
comings that I sought to remedy. I believe I have largely accomplished
Thats all for now. I will have much more to say on this topic in the coming days.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk