From: Robert Ramey (ramey_at_[hidden])
Date: 2006-06-28 13:02:18
Actually, we're going in the other direction. That is, my inclination
now is for aprogram to support throwing an exception if an
attempt is made to read a class whose verision number is
greater than that in existence when the program was compiled.
I believe that implementation of something such as you describe
below should be outside of the serialization system itself. That is
your class would have its own "version" variable which
would be saved/loaded before all other members. This would
then be totally within the control of your own code.
Having said this, there is a case for excluding all the versioning
from the serialization library itself - and I seriously considered
doing so. In the end though, I decided to include the most
commonly need idea for versioning. Beyond that, I believe
that it's really application specific and would apply the
approach outlined above.
John Haller wrote:
> Has there been consideration to supporting setting
> the class version on output? This is useful when
> transmitting classes over a network without requiring
> both sides to be at the same software version. While
> the current version support allows the newer side
> to interpret an older message format, there is no
> way for the newer side to use the older serialization.
> This requires an immediate transition of all communicating
> parties to a common version, which is unreasonable
> in a heterogeneous network.
> Implementation probably has a number of issues, as
> there could be multiple connections, each with its
> own ideas of supported versions for each class.
> How the two sides agree on a class version is
> outside the scope of serialization, although
> a companion framework may be suitable. But
> support for specification of version information
> for use by transmit serialization is required
> to be able to write such a companion class.
> There may also need to be some support in the
> archive templates to associate a particular class
> with a particular output version.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk