In-Reply-To: <[EMAIL PROTECTED]> On Wed, 11 Dec 2002 15:52:10 -0800 (PST) Augustus Saunders ([EMAIL PROTECTED]) wrote: > In a nutshell, I gave these definitions: > > Persistance == Transformationless && Symmetric > Serialization == Lossy && (Symmetric || Asymmetric)
I think the terms on the right are more useful than the terms on the left :-) Here is a more detailed set of discriminating questions that we can ask: o Is the format symmetric? Can saved objects be reloaded without loss? o How easily can the format be understood by humans? Eg does it need decoding like a hex dump, or is it readable by techies like XML, or is it suitable for use by non-technical end-users like the output of a report-generator? o How portable is the format between applications/compilers/platforms? o How verbose is the format? How efficient in time and space? o What cooperation does the format need from the user-defined type? Is any UDT-specific code needed at all? Can types be loaded without changing their source code? o What variations in schema can be accommodated? How much does this depend on hand-coding in the user-defined type, and how much is managed automatically from met-data in the archive? o How much redundancy is there between loading and saving? Can a single routine or set of metadata do both jobs? o What validation does the archive provide? Can the archive detect gross corruption? Are integers checked against user-defined ranges? Robert Ramey's submission had a particular set of answers to many of these questions. For example, he seemed to believe that only symmetric formats should be supported and that it did not need to be human readable. My feeling is that the scope can be broadened fairly painlessly, at least a little further. > Further, you have identified a couple of types of transformations > that you feel are important. Well, as I think the original > discussion showed, people have a wide variety of desired output > types and styles It would be helpful to collate a list of candidate format types and styles. My fear is that some format types will turn out to be incompatible with each other. That if we support, say, XML, we will prevent support for some other format. (I think this danger is why Robert didn't want to go down this path.) My hope and tentative belief is that, on the contrary, any system which can support XML will be compatible with all other formats. I welcome counter-examples. -- Dave Harris _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
