From: [EMAIL PROTECTED] (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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost