|
Boost : |
From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-04-18 19:43:51
Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
> Well, I believe you are taking too narrow a view here. These 'old'
> proprietary formats may not be old or replaceable. They are just part of the
> landscape on many projects. For example,
[ snip]
This is exactly the type of problem I'm familiar with. Of course, the protocol
can be arbitrarily complex - often propropionate to the longevity of the
system, with increasing gnarliness the older its inception.
> This design works great. There is a clear mapping from the protocol
> specification to the message classes and all the details of the 'physical'
> protocol are in a single archive class. Of course if you sent some sort of
> message down pipe that wasn't of the correct type to go to the remote
> computers, the serialization part of the framework won't stop you. But we
> prevented that in other layers of the architecture.
If you're lucky enough to work on a C-based system utilising such formats,
you'll quickly realise how superior this design is to older methods!
> I believe that Matthew has now demonstrated that archive extension is
> possible, which I believe is one of the major changes from the first review.
Archive extension is certainly possible - the only limitation is that no other
information attends the serialization operation of a given object - I would
love to see somebody creating a non-serial archive!
> That said, any documentation of this process would clearly be a plus. In a
> typical proprietary archives writing of the version and type numbers will need
> to be shut off. So I can imagine documenting these sorts of issues.
Yes, the documentation here won't need to be extensive. Just describe the
initialisation phase of an archive (writing the preamble), and describe
the difference between overriding the 'save', 'save_override' and 'operator<<'
options. Possibly, the 'version_type', 'tracking_type' etc. elements
should be described in more detail.
Would there be any reason for an archive to modify the object registration
process?
Matt
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk