Re: [Boost-users] [serialization] class versioning changes in boost 1.42

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-02-27 13:44:45

Jarl Lindrud wrote:
> Robert Ramey <ramey <at> rrsd.com> writes:
>
>>
>> Jarl Lindrud wrote:
>>
>>>> Can Microsoft 2003 word load files created with Microsoft word
>>>> 2007? That is what we're talking about here.
>>
>>> Of course it can. Try it yourself (Word 2007 -> File -> Save As ->
>>> select the relevant file type). This capability is fundamentally
>>> important for many applications, and there's nothing magic or
>>> logically impossible about it.
>>
>> Please reread my sentence above.
>
> Let me try to make this more clear to you.
>
> * Word 2007 can save files in a format that will *not* be readable by
> Word 2003.
> * Word 2007 can *also* save files in a format that *will* be readable
> by Word 2003.

LOL - Microsoft 2003 cannot load files created by Microsoft
word 2007 unless they are specifically saved with that compatibility
in mind.

The ability to create a file compatible with some previous version is
not supported by the library.  The question has come up, and a cursory
examination showed that it wouldn't be too hard to do.  This is
mentioned at the end of the documentation as ideas for future
projects.  But no one has had enough interest to work on this.

> With Boost.Serialization I *cannot* make a program that produces
> archives that are guaranteed readable by programs that I've already
> built and deployed, because those earlier programs may well use an
> earlier version of Boost.

You can if you've used a class verision number which is less than 8 bits.
Have you saved files with version # greater than 255?

> And as you yourself acknowledged, in regard to point 2 in my very
> first post, archives created with newer Boost versions are not
> guaranteed to be readable by older Boost versions.

This is of course not true.  One thing is Boost version.  Class
versions are an entirely different thing which has absolutely
nothing to do with class version.  I know I've said it
before, but I can't believe you actually understand the
issues here.

> In fact, you stated that you don't even see any utility in such a
> capability, and then later that it is somehow logically impossible.

I'm talking about class versions here.

> Can you at least see that there are serious real world applications
> (Word, for starters) that have this capability as a fundamental
> requirement?

Word can't do this. No program can.  Microsoft word 2003
cannot read a file saved in Microsoft word 2007 format.

> Boost.Serialization currently does not support this kind of
> versioning. Fair enough. But let's not pretend that it's some
> academic feature that no-one is interested in.

LOL

>>> Networked applications need this capability as well. E.g. a newly
>>> developed client needs to be able to communicate with any number of
>>> older, deployed, servers.

It can and it does.

>> This capability is and has always been part of the serialization
>> library. It it included in the documentation, demos and tests.
>> Please read the documentation.
>>
>
> If the previously deployed servers use Boost 1.35.0, say, and my new
> client uses Boost 1.42.0, how can you claim that the new client will
> be able to send valid messages to the older servers? The
> Boost.Serialization documentation explicitly states that such
> compatibility is *not* supported (To Do -> Back Versioning). You even
> said so in earlier posts.

LOL

> What am I missing?

You're totally lost here.  I think I see it now.  And this has in fact
come up before.  You've somehow got the idea that class
versioning is somehow related to boost version #.  The boost
version # refers to the version of the serialization library code.

The class version refers to the version of the class in one's own
program.  These are totally unrelated concepts whose only
commonality is the word "version".

The current boost serialization library can read archives
created 10 years ago.  The only requirement is that
if the users code has added members, then the
loading of those members has to be conditional on a
class version number.  The library assumes that this
class version number is small integer.

>> It's only a guarentee if one follows the rules.  In fact he did get

> So there are unknown rules one should follow... Are there more
> unknown rules? Is the end user responsible for knowing about these
> unknown rules?

I'd have to go back and check the documentation to see what it
says about version numbers.  The examples all show small
version numbers and the function signature uses "int" which
the C++ standard permits to be at least as small as 16 bits.
Also the binary_archive breaks if one tries to use a 32 bit
integer.  So it never occurred to me that someone might try
to store a 32 bit number for the class version.  In the latest
iteration, we decided to compile boost at the highest warning
level.  Eliminating warnings resulted in including code to trap
the storage of version # that are too big.  So in the future
these rules are better enforced.

>> lol - I write 30,000 lines of code with the intention of making no
>> errors.  I cannot guarentee that I have made no errors.

> Car makers know that their cars are not perfect. When they offer you a
> guarantee, it doesn't mean "the car will never break down". It means,
> "if the car breaks down, we will fix it.".

There is a very simple fix - one line of code that can fix this users
code. He can include it in his own version of the library and will
have no problems loading his older files.  This fix basically backs
out the recent change and would prevent detection problems of
this nature in the future.  That's why I don't want to do it.

> If Boost.Serialization's guarantee of backwards compatibility only
> applies under "anticipated usage" (as defined by yourself), then I
> guess that should be documented, along with your definition of
> "anticipated usage".

I'll add language to the documentation so that it's clear one should
not use a number larger than 255 as a class version number.  And
I'll enhance the code to trap on violations of this rule in the future.

Robert Ramey