[serialization] Richer "tagged" fields and polymorphic archive types

Robert,
First let me start off by thanking you for the excellent Boost
Serialization library. I'm planning to use it as part of a new system
I'm building at my place of work as a more flexible replacement for
Rogue Wave's "saveGuts/restoreGuts". I've been able to implement my
own archive types without too much of a struggle, and have been
overall very impressed with the functionality of the library and its
documentation.
Now some background and then on to the questions :)
I'm not sure if you are familiar with TIBCO's "Rendezvous" messaging
middleware product (http://tibco.com/) or with the FIX protocol
(http://fixprotocol.org/) but these are both commonly used in
financial services applications. Rendezvous as a messaging transport
and FIX as a general message convention and data dictionary. FIX also
specifies a "session" layer used for communication, but thats out of
scope here.
Both Rendezvous (RV) and FIX support the concept of numeric field
identifiers in their messages. In FIX, serialized messages look like
TAG=VALUE\x01TAG=VALUE\x01... where TAG is an integer field ID and
VALUE is the value associated with that tag and \x01 is an ASCII SOH
character. In RV messages, fields may be given a name and/or an
integer field ID. So it is pretty straightforward to represent a FIX
message as an RV message (or vice-versa) if you always use these
numeric IDs. Also, these "tagged" message formats facilitate
interchange of data between different systems because they do not
place stringent requirements on field ordering or even field presence
in some cases.
In the system I'm working on, the fundamental object types can all be
mapped more or less directly to messages in the FIX specification.
OK, so now onto the meat of the question.
What I'd like to use in this application is something akin to NVP
serialization for my objects, but which I'll call FIELD serialization.
Every member of an object can be associated with a FIELD ID which
would contain both a name and an integer ID (e.g. "Price" and 44).
The universe of field IDs is more or less static and well-known.
To this end I've created two utility classes called field_id and
field. The field_id class is a std::pair

Using NVP as a model is a good start and good decision. But I see your problem. Take the following with a large grain of salt as I'm really just speculating without really thinking. instead of handling FIELD as a member function in your archive like xml archives to with NVP, consider the following: a) make a FIELD wrapper similar to make_nvp - I assume you've already got this. Note that you should set the new "is_wrapper" trait described in the latest version 1.35 checked in to the HEAD branch. This will permit the FIELD type to pass through the compile time traps which detect unwise behaviour. Alternatively, you can disable the compile time trap. See the last section in "Rationale" regarding the compile time trap. b) implement serialization for objects of FIELD type in more or less the normal way. Use NVP as a model. This will permit serialization of your FIELD with any archive. I don't know if you've done this yet c) Make your own archive .... but DON"T do what xml_archive does with NVP. That is, don't include an override for FIELD in the archive class itself. d) make your own specializations for the function template serialize. (Assuming non-intrusive serialization here), (Assuming compiler supports partial function template ordering correctly). template<class T> void serialize(tibco_oarchive & ar, field<T> &t, const unsigned int version){ ... // special stuff for "field" } and template<class T> void serialize(polymorphic_tibco_oarchive & ar, field<T> &t, const unsigned int version){ ... // special stuff for "field" } note that this code can be included in your header "field.hpp" so that is seen when and only when you're using FIELD. This will move the "extra specical sauce" for FIELDS on the tibco_oarchive to inline code BEFORE it even gets the polymorphic archive itself. There could be a problem with start/end though. "I'm building at my place of work as a more flexible replacement for Rogue Wave's "saveGuts/restoreGuts"." Wow - I wish I'd thought of THAT name. Robert Ramey
participants (2)
-
Caleb Epstein
-
Robert Ramey