I'm just reposting from the list: *****************************original message***********************
Dave Harris wrote: >>1. Agreement on terms. In particular, I strongly suggest beginning >> with the definitions of serialization and persistence outlined by >> Augustus Saunders in >> http://lists.boost.org/MailArchives/boost/msg39598.php. I realize >> that Robert didn't like those definitions, but they resonated for >> most people (including me), and seem to provide an excellent >> starting point. >> >> > >For what it's worth, I didn't like those definitions. In my view >serialisation is the right name for what the submitted library did. >Persistence is just serialisation to a persistent medium. Persistence is a >property of media rather than formats. It all but comes for free once you >have decent serialisation. > This is, in fact, why we need agreement on terms. At a fundamental level, we may not even agree on the significant axes of differentiation. This is really the problem, not the labels that we apply to our distinctions. We can call different catagories of goals A, B, C, and so forth for all that it matters. Since my definitions got pushed to the forefront, I'll try and clarify why I made the distinctions I made and why I think it is a worthwhile distinction. In a nutshell, I gave these definitions: Persistance == Transformationless && Symmetric Serialization == Lossy && (Symmetric || Asymmetric) The reason why I drew up these distinctions is based on how the user winds up using a library, and what information must be intrinsically provided (ie, can in no concievable way be automatically deduced) to the library. Basically, it is my feeling that if we cannot make transformationless persistance fairly transparent through type metaprogramming, then we need to go back to the drawing board and figure out what we need to make it fairly transparent. On the other hand, anything that requires a transformation to be applied on the data being stored intrinsically cannot be transparent--somebody has to write the transformation. So, from the perspective of library writing, Persistance should be a poster child for type metaprogramming. Serialization, on the other hand, is a transformation framework, where we identify common modes of transformation in order to make it easier for other people to create their favorite transformations of whatever kind. Application writers would directly use a persistance library, but a Serialization library would actually be for other library writers, with the exception of whatever sample transformations we cared to provide as examples. In defence of my terms, the purpose of Serialization is to encode data as a serial sequence of bytes. The purpose of Persistance is to make data persist from one running of an application to the next running of the same application. If Persistance serializes the data it persists for efficiency reasons (rather than say just doing a RAM dump and restore), that is an implementation detail, so to speak. If my definitions seem circular, it is because I think my usage of the terms (capitalized) is in line with standard usage of the terms. At any rate, I do NOT want to quibble over terms, I want to iron out what distinctions are relevant *for the purposes of creating and using libraries*. We can label the categoriesin any generic fashion that suits our tastes. >But I agree there is a need to separate plain serialisation from data >conversion/formatting/filtering. With XML, for example, the intent is not >so much to save and load the data (there are more efficient ways of doing >that), but to work on the data in its XML form with XML tools. > >It is maybe worth identifying another possible purpose, that of reporting >or logging, where the serialised output is meant to be read by a human. >For this it may not be necessary to have input archives, just output >archives. > >For the sake of concreteness, I suggest "serialisation", "conversion" and >"logging". > So the goal that I intend to achieve with "Persistance" you intend to achieve with "Plain Serialization." As explained somewhat above, I think that plain serialization has a sufficiently different use case that we should have a seperate library for it. Also, I don't want to pigeonhole plain serialization to using a serial back end. 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, and so we need to allow them to easily write their own transformations that can be plugged into a serialization library. I feel that it is more important that we work out what *types* of transformations to support rather than which specific formats (except as example for a given type). >>2. Careful description of scope. Answer questions like: >> * Is this a persistence or serialization library? >> >> <snip> Given the terms Dave was using when he asked this question, then your answer could be summed up as serialization :) Anyway, I agree; that's what I said in my original post. With one caveat, though. I think that plain serialization (your term) should be explicitly *not supported* and defer that use case to a safer, more airtight approach with a persistance library. Thanks for your input! Cheers- Augustus __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
