[boost] Re: Serialization Review Results

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-12-14 13:18:32

From: brangdon_at_[hidden] (Dave Harris)

>> One thing that my usage of "serialization" does not include is 
>> transformation or mapping to any other arbitrary format.  Some
>> formats may not be rich enough to capture the "meaning" of the
>> set of objects in a useful way.  For example capturing an
>> arbitrary set of C++ objects in a CSV file might be possible,
>> but it would be no richer than a simple sequence of bytes.
>> Hence, though possible, it would be pointless.

>Let's say I have a bunch of C++ objects that I want to export to a 3rd 
>party spread-sheet, eg to draw a pretty graph, and the spread-sheet only 
>understands CSV. Is there any reason I shouldn't write an archive class to 
>generate CSV directly? I don't care if the full "meaning" is not captured, 
>provided I get enough for the spread-sheet to do its stuff.

[snip]..

Perhaps pointless is was not a well chosen word.  Let me change the last
sentence above to the following:

Hence, though possible, it would not result in a CSV file that would normally
be useful to applications which process such files.

If you do have a requirement to generate a CSV file compatible for some particucular
application (e.g. loading into an excel spreadsheet or into a database table)
I can't imagine how a serialization library would offer benefit over the usage
of iostreams directly.

The fundamental problem that Serialization addresses is the reversable deconstruction
of an arbitrary set of C++ objects to a stream of bytes.  That's all it is.  We know that it
is useful for certain things, but that doesn't mean its going to be useful for everything.

If that's not what you want to do, then such a library is not going to be of help and
some other method or tool will have to be used.

This whole discussion is not about serialization but about a completly different
topic. It seems that there is a strong belief that there can be created a
generic system which will map an arbitrary set of C++ objects in a meaningful
way to another other format.  Such a system will necessarily have to start
with a system of reflection that describes all aspects of data structures
that the system aspires to support. For example, if XML is to be supported,
items will have to have external names.  Once this system of reflection (or meta-data)
were specified, then importers/exporters to from/to each file format would be
created.  There is at least one commercial product that does this (Data Junction)
This is a hugely ambitious undertaking that is only tenously related to serialization.

I was unprepared for the response to the submission of the serialization library
for formal review.  I had expected some flack over implemenation issues (indeed
I got my share).  I had a lot difficulty getting this implemented.  The wide variety
of compiler issues made things much more difficult.  I got some flack over 
interface issues - basically "registration" and "describe".  I was sensitive to these
issues but hadn't been able to come up with good implemenations of these
features.  ( BTW, the review process has given me new ideas and information
regarding these issues and I believe they can be addressed in a satisfactory 
way.)  Someone always complains that the generic solution is "not efficient"
and wants it to have more specific features.  I am generally skeptical of these unless
accompanied by hard data which is almost never submitted.

What really through me for a loop was that most of the objections to the 
submissions were that it wasn't something else.  It seems that there was
a fundamental difference between what users expected a "serialization" library
to do and what serialization  libraries generally do (Common C++, and MFC in particular
as well as references
http://www.riehle.org/computer-science-research/1996/plop-1996-serializer.html 
)

In this aspect I believe that the review results fairly reflected the views of those who commented
on the issue.  However, I believe the rejection was for the wrong reasons.  This has
led to the current discussion which I believe is really not about serialization at all.

Robert Ramey