Date: Fri, 22 Nov 2002 16:34:46 -0800 (PST) From: Augustus Saunders <[EMAIL PROTECTED]>
>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 definitions. 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 that purpose. Thats all for now. I will have much more to say on this topic in the coming days. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
