
On Fri, 26 Feb 2010 21:44:04 -0800
"Robert Ramey"
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)