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

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42 [patch]
From: David Raulo (david.raulo_at_[hidden])
Date: 2010-02-27 05:24:17

On Fri, 26 Feb 2010 21:44:04 -0800
"Robert Ramey" <ramey_at_[hidden]> wrote:

> Jarl Lindrud wrote:
> 
> > 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.
> 
> 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.

I think he did, but you did not understand his point. In order to allow
newer clients talk to older servers, you need forward compatibility in
addition to backward compability (that is to say, the newer client
needs to save archives in the format understood by the older server).
Boost serialization only tries to provide the later.  Google protocol
buffers do offer forward compatibility, but have little to do with
serialization.  http://en.wikipedia.org/wiki/Forward_compatibility

Anyway, this is getting very OT. 

> > I'm confused. You indicate here that backwards compatibility is an
> > *intention*, and yet the Boost.Serialization documentation indicates
> > that backwards compatibility is a *guarantee* (Contents -> To Do ->
> > Back Versioning -> "... Currently, the library permits one make
> > programs that are guarenteed the ability to load archives with
> > classes of a previous version...").
> 
> This is all true. The only restriction is that
> [...]
>  It was never the intention of the library
> to support this [...]

Again you are missing his point. Sure you could not anticipate this,
this is still a regression. An accidental, unanticipated one.   I am
myself a software library writer. When I make such a guarantee, this is
a promise to my users that if it ever breaks (accidents happen), I fix
it.   If I do not make any such claim, then my users are to keep the
pieces.  But of course this must be clearly understood by all parties,
and put prominently in the documentation. This is just being honest.

I would perfectly understand that you drop the claim of offering any
guarantee of backward compatibility, just a best-effort. This is, after
all, free software.  You volonteered an enormous quantity of time
writing this impressive library for free, and for that I'm grateful.

> It's only a guarentee if one follows the rules.

Your rules aren't written anywhere...  I honestly do not know what
other implicit rules I unintentionally broke by just using the library.
In other terms, it is now obvious to me I actually have no guarantee.

We are only suggesting you to make that clear in the documentation, so
new user can acess the risk they are taking, and balance that against
the many benefits of using boost serialization.

> In fact he did get
> a compile error when he tried to use a binary_archive which in fact
> checks the size of the version number passed. 

no no no. This behavior is new.  Before boost 1.42 I never got compile
errors, and in fact I had no way of knowing what I was doing was
"against the rules".

This is becoming ridiculous. Can we please get back to the
actual issue?  Here are the facts :

- boost_version  used to be an unsigned int, which for the vast
  majority of your users was 32 bits at least;
- boost 1.42 changed that to 16 bits;
- in your mind it was always 8 bits and you were just trying to enforce
  this in a more explicit way;
- this is not mentionned anywhere in the documentation or in the API.
- you have at least one user who lost backward archive compatibility
  because of this.

See below a patch against svn.  Can we please discuss its advantages
and drawbacks?

- what good does it do: obviously in my case, restore backward
  compatibility.

- it gives more flexibility to the versioning scheme.  Two usefull such
  schemes were described previously in the discussion, where classes
  still have increasing integer versions, but are not possible with 8
  bits storage.

- what downsides does appying this patch have?  Maybe occuring a slight
  overhead on 16-bits platforms?  If true, can this be actually
  measured?

- Would this patch cause any regression? Break any user code which was
  working fine before?  Break user archive backward compatibilty?

Thanks,

David.

Index: boost/archive/basic_archive.hpp
===================================================================
--- boost/archive/basic_archive.hpp     (revision 59943)
+++ boost/archive/basic_archive.hpp     (working copy)
@@ -37,7 +37,7 @@
 } /* boost */                                     \
 /**/
 
-BOOST_ARCHIVE_STRONG_TYPEDEF(uint_least16_t, version_type)
+BOOST_ARCHIVE_STRONG_TYPEDEF(uint_least32_t, version_type)
 BOOST_ARCHIVE_STRONG_TYPEDEF(int_least16_t, class_id_type)
 BOOST_ARCHIVE_STRONG_TYPEDEF(int_least16_t, class_id_optional_type)
 BOOST_ARCHIVE_STRONG_TYPEDEF(int_least16_t, class_id_reference_type)