Re: [Boost-users] boost::serialization and PHP websites
Pascal Kesseli writes:
Currently, I consider the boost serialization a de-facto standard for C++ serialization issues.
In 2007 it wasn't a stretch to say that General Motors was a de facto standard in the automobile industry. Now they want 70 billion from taxpayers. Oh my G-d! -- Brian Wood Ebenezer Enterprises www.webEbenezer.net "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"
Brian Wood wrote:
Pascal Kesseli writes:
Currently, I consider the boost serialization a de-facto standard for C++ serialization issues.
In 2007 it wasn't a stretch to say that General Motors was a de facto standard in the automobile industry. Now they want 70 billion from taxpayers. Oh my G-d!
Hey Robert, if you start getting 70 billion from taxpayers, please let me get in on it too. I did that talk one time at the place with the people... I use the library but even I don't think Boost Serialization should be considered a de-facto standard. You need to make sure the library meets your requirements first. Boost serialization currently does not elegantly handle forward compatibility, for example. Everything else is cool to me though. -- Sohail Somani http://uint32t.blogspot.com
Sohail Somani wrote:
Boost serialization currently does not elegantly handle forward compatibility
This would be doable if someone wanted to invest the effort. And this would not be a huge effort at least in comparison to the efforts required to implement a lot of the other features of the library. Robert Ramey
Robert Ramey wrote:
Sohail Somani wrote:
Boost serialization currently does not elegantly handle forward compatibility
This would be doable if someone wanted to invest the effort. And this would not be a huge effort at least in comparison to the efforts required to implement a lot of the other features of the library.
How would this be done (without breaking backward compatibility)? It is kind of late so admittedly it might be totally obvious in the morning. I also notice you have not mentioned anything about the 70 billion dollar bailout for the serialization library and spreading the wealth. I assume the cheque's in the mail. -- Sohail Somani http://uint32t.blogspot.com
Sohail Somani wrote:
Robert Ramey wrote:
Sohail Somani wrote:
Boost serialization currently does not elegantly handle forward compatibility
This would be doable if someone wanted to invest the effort. And this would not be a huge effort at least in comparison to the efforts required to implement a lot of the other features of the library.
How would this be done (without breaking backward compatibility)? It is kind of late so admittedly it might be totally obvious in the morning.
I also notice you have not mentioned anything about the 70 billion dollar bailout for the serialization library and spreading the wealth. I assume the cheque's in the mail.
I purposely overlooked that comment. It seemed to be an attempt at some sort of criticism. It's absolutely amazing to me how much I've been criticised (many times personally) for making this library. I choose to interpret this as acknowledgement (and perhaps resentment) of its success. It's my policy to ignore such comments which almost always results in the least amount of time wasted. Occasionally this doesn't work so I have to waste more time. But generally this policy works well for me. Robert Ramey
Robert Ramey wrote:
Sohail Somani wrote:
Robert Ramey wrote:
Sohail Somani wrote:
Boost serialization currently does not elegantly handle forward compatibility This would be doable if someone wanted to invest the effort. And this would not be a huge effort at least in comparison to the efforts required to implement a lot of the other features of the library. How would this be done (without breaking backward compatibility)? It is kind of late so admittedly it might be totally obvious in the morning.
I also notice you have not mentioned anything about the 70 billion dollar bailout for the serialization library and spreading the wealth. I assume the cheque's in the mail.
I purposely overlooked that comment. It seemed to be an attempt at some sort of criticism. It's absolutely amazing to me how much I've been criticised (many times personally) for making this library. I choose to interpret this as acknowledgement (and perhaps resentment) of its success. It's my policy to ignore such comments which almost always results in the least amount of time wasted. Occasionally this doesn't work so I have to waste more time. But generally this policy works well for me.
Robert Ramey
I know you get a lot of questions about things that are clearly addressed in the serialization documentation (from myself too a few times). I've even heard you called "that RTFM guy on the boost lists" a couple times :) I couldn't handle maintaining such a widely-used library myself and would like to express my gratitude for tackling such a complex problem free of charge and creating something that has been very useful to us.
Kenny Riddile wrote:
Robert Ramey wrote:
Sohail Somani wrote:
Robert Ramey wrote:
Sohail Somani wrote:
Boost serialization currently does not elegantly handle forward compatibility This would be doable if someone wanted to invest the effort. And this would not be a huge effort at least in comparison to the efforts required to implement a lot of the other features of the library. How would this be done (without breaking backward compatibility)? It is kind of late so admittedly it might be totally obvious in the morning.
I also notice you have not mentioned anything about the 70 billion dollar bailout for the serialization library and spreading the wealth. I assume the cheque's in the mail.
I purposely overlooked that comment. It seemed to be an attempt at some sort of criticism. It's absolutely amazing to me how much I've been criticised (many times personally) for making this library. I choose to interpret this as acknowledgement (and perhaps resentment) of its success. It's my policy to ignore such comments which almost always results in the least amount of time wasted. Occasionally this doesn't work so I have to waste more time. But generally this policy works well for me.
Robert Ramey
I know you get a lot of questions about things that are clearly addressed in the serialization documentation (from myself too a few times). I've even heard you called "that RTFM guy on the boost lists" a couple times :)
I should say that answering the question can sometimes be tedious. But usually its one of the more pleasurable aspects of being a library author. As I'm pretty familiar with the library, I can just answer of the top of my head so it's very easy. (But by the same token, the answers are sometimes incorrect - oh well). And questioners are grateful (Who wouldn't be after banking their head against the wall for a day). I'm always happy to incorporate improvements to the manual which are submitted as trak items. I've appended a section called "Tips and Tricks" or FAQ (I don't remember now). So if you wasted a lot of time on something that was in retrospect obvious, you're free to vent your frustration by submitting an item to that tlist.
I couldn't handle maintaining such a widely-used library myself and would like to express my gratitude for tackling such a complex problem free of charge and creating something that has been very useful to us.
LOL - I would be happy to accept any compensation anyone want's to offer to salve any guilt consciences about getting such a great deal. In fact, I have on occasion made extensions to the library under contract. I'm a self-unemployed software developer and I've spent time on the library when I have nothing else to do. I answer question because I just like to chat. Robert Ramey
Robert Ramey wrote:
Sohail Somani wrote:
Robert Ramey wrote:
Sohail Somani wrote:
Boost serialization currently does not elegantly handle forward compatibility This would be doable if someone wanted to invest the effort. And this would not be a huge effort at least in comparison to the efforts required to implement a lot of the other features of the library. How would this be done (without breaking backward compatibility)? It is kind of late so admittedly it might be totally obvious in the morning.
I also notice you have not mentioned anything about the 70 billion dollar bailout for the serialization library and spreading the wealth. I assume the cheque's in the mail.
I purposely overlooked that comment. It seemed to be an attempt at some sort of criticism. It's absolutely amazing to me how much I've been criticised (many times personally) for making this library. I choose to interpret this as acknowledgement (and perhaps resentment) of its success. It's my policy to ignore such comments which almost always results in the least amount of time wasted. Occasionally this doesn't work so I have to waste more time. But generally this policy works well for me.
Just to clarify, my comments were meant as a joke so I apologize if you were offended. Still interested in forward compatibility, if you are inclined to elaborate a little. -- Sohail Somani http://uint32t.blogspot.com
Sohail Somani wrote:
Robert Ramey wrote:
Sohail Somani wrote:
Robert Ramey wrote:
Sohail Somani wrote:
Boost serialization currently does not elegantly handle forward compatibility This would be doable if someone wanted to invest the effort. And this would not be a huge effort at least in comparison to the efforts required to implement a lot of the other features of the library. How would this be done (without breaking backward compatibility)? It is kind of late so admittedly it might be totally obvious in the morning.
I also notice you have not mentioned anything about the 70 billion dollar bailout for the serialization library and spreading the wealth. I assume the cheque's in the mail.
I purposely overlooked that comment. It seemed to be an attempt at some sort of criticism. It's absolutely amazing to me how much I've been criticised (many times personally) for making this library. I choose to interpret this as acknowledgement (and perhaps resentment) of its success. It's my policy to ignore such comments which almost always results in the least amount of time wasted. Occasionally this doesn't work so I have to waste more time. But generally this policy works well for me.
Just to clarify, my comments were meant as a joke so I apologize if you were offended.
Still interested in forward compatibility, if you are inclined to elaborate a little.
Here we go. Basically, backward compatibility is handled by code that looks like the following: template<class Archive> void save(Archive &ar, const unsigned int version){ ar << original_stuff ar << stuff_added_version_3; ar << stuff_added_version_4; } template<class Archive> void load(Archive &ar, const unsigned int version){ ar >> original_stuff; if(version > 3) ar >> stuff_added_version_3; if(version > 4) ar >> stuff_added_version_4; ... } So what we need to do is replace the save above with: template<class Archive> void save(Archive &ar, const unsigned int version) const { ar << original_stuff if(version > 3) ar << stuff_added_version_3; if(version > 4) ar << stuff_added_version_4; } So that would be fine. Right now version for class T is set with BOOST_CLASS_VERSION(T, 4) To generate an original version of the archive "just" use BOOST_CLASS_VERSION(T, 0) So we're almost there. To make a "real" system you need to use something like: BOOST_CLASS_VERSION(T, VERSION(T, date)) where VERSION is macro which retures the version used as of the given date (or someother "global" versioning scheme).. This would be implemented as some sort of new header to implement this facility. This might not be the exact implemenation, perhaps a variation of BOOST_CLASS_VERSION would have to be implened - whatever. The real point is that this would require very little - if any - changes to the "guts" of the library. Robert Ramey
Robert Ramey wrote:
Sohail Somani wrote:
Still interested in forward compatibility, if you are inclined to elaborate a little.
Here we go. Basically, backward compatibility is handled by code that looks like the following:
template<class Archive> void save(Archive &ar, const unsigned int version){ ar << original_stuff ar << stuff_added_version_3; ar << stuff_added_version_4; }
template<class Archive> void load(Archive &ar, const unsigned int version){ ar >> original_stuff; if(version > 3) ar >> stuff_added_version_3; if(version > 4) ar >> stuff_added_version_4; ... }
So what we need to do is replace the save above with:
template<class Archive> void save(Archive &ar, const unsigned int version) const { ar << original_stuff if(version > 3) ar << stuff_added_version_3; if(version > 4) ar << stuff_added_version_4; }
Just typing out loud: Forward compatibility is the ability to load an archive with a version of 4 into an application with a version of 3. So if we have std::vector<SomeClass> and in version 4, I add an int to SomeClass, I'm pretty sure it would cause the whole thing to go boom when loading an archive from version 4 into version 3. I'm not sure if the above avoids this problem, does it? -- Sohail Somani http://uint32t.blogspot.com
Sohail Somani wrote:
Robert Ramey wrote:
Sohail Somani wrote:
Still interested in forward compatibility, if you are inclined to elaborate a little.
Here we go. Basically, backward compatibility is handled by code that looks like the following:
template<class Archive> void save(Archive &ar, const unsigned int version){ ar << original_stuff ar << stuff_added_version_3; ar << stuff_added_version_4; }
template<class Archive> void load(Archive &ar, const unsigned int version){ ar >> original_stuff; if(version > 3) ar >> stuff_added_version_3; if(version > 4) ar >> stuff_added_version_4; ... }
So what we need to do is replace the save above with:
template<class Archive> void save(Archive &ar, const unsigned int version) const { ar << original_stuff if(version > 3) ar << stuff_added_version_3; if(version > 4) ar << stuff_added_version_4; }
Just typing out loud: Forward compatibility is the ability to load an archive with a version of 4 into an application with a version of 3.
To me forward compatability is he ability to create a version 3 archive with a version 4 program. Hmmm - now that I read that, it doesn't look right. I guess that should be called "complete" backward compatibility. I don't see how it is possible while writing version 3 progam to know what version 4 is going to save.
So if we have std::vector<SomeClass> and in version 4, I add an int to SomeClass, I'm pretty sure it would cause the whole thing to go boom when loading an archive from version 4 into version 3.
I'm not sure if the above avoids this problem, does it?
AMDG Robert Ramey wrote:
Sohail Somani wrote:
Just typing out loud: Forward compatibility is the ability to load an archive with a version of 4 into an application with a version of 3.
To me forward compatability is he ability to create a version 3 archive with a version 4 program. Hmmm - now that I read that, it doesn't look right. I guess that should be called "complete" backward compatibility. I don't see how it is possible while writing version 3 progam to know what version 4 is going to save.
It would be possible in special cases. For example, the version 4 archive could add information that the version 3 program knows to skip somehow. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Robert Ramey wrote:
Sohail Somani wrote:
Just typing out loud: Forward compatibility is the ability to load an archive with a version of 4 into an application with a version of 3.
To me forward compatability is he ability to create a version 3 archive with a version 4 program. Hmmm - now that I read that, it doesn't look right. I guess that should be called "complete" backward compatibility. I don't see how it is possible while writing version 3 progam to know what version 4 is going to save.
It would be possible in special cases. For example, the version 4 archive could add information that the version 3 program knows to skip somehow.
Right, so one totally naive way the library could do it would be to inject a marker after every serialization call. This way, the version 3 application could simply search for the marker after every serialization call in order to set up the next serialization call. Basically, I am saying that version 4 of the app writes out: foo 1 2 3 |END_MARKER| foo 4 5 6 |END_MARKER| And version 3, which can only read the first two ints, reads foo 1 2 and then resets the stream pointer (or whatever) to right after |END_MARKER|. If that makes ANY sense, I will be happy. -- Sohail Somani http://uint32t.blogspot.com
Sohail Somani wrote:
Steven Watanabe wrote:
AMDG
Robert Ramey wrote:
Sohail Somani wrote:
Just typing out loud: Forward compatibility is the ability to load an archive with a version of 4 into an application with a version of 3.
To me forward compatability is he ability to create a version 3 archive with a version 4 program. Hmmm - now that I read that, it doesn't look right. I guess that should be called "complete" backward compatibility. I don't see how it is possible while writing version 3 progam to know what version 4 is going to save.
It would be possible in special cases. For example, the version 4 archive could add information that the version 3 program knows to skip somehow.
Right, so one totally naive way the library could do it would be to inject a marker after every serialization call. This way, the version 3 application could simply search for the marker after every serialization call in order to set up the next serialization call.
Basically, I am saying that version 4 of the app writes out:
foo 1 2 3 |END_MARKER| foo 4 5 6 |END_MARKER|
And version 3, which can only read the first two ints, reads foo 1 2 and then resets the stream pointer (or whatever) to right after |END_MARKER|.
If that makes ANY sense, I will be happy.
You might be able to implement that for xml archives by deriving from xml_iarchive. Robert Ramey
Robert Ramey wrote:
Sohail Somani wrote:
Basically, I am saying that version 4 of the app writes out:
foo 1 2 3 |END_MARKER| foo 4 5 6 |END_MARKER|
And version 3, which can only read the first two ints, reads foo 1 2 and then resets the stream pointer (or whatever) to right after |END_MARKER|.
If that makes ANY sense, I will be happy.
You might be able to implement that for xml archives by deriving from xml_iarchive.
I never use xml archives but xml in general does have this property. I'd like the solution to apply to all archives though. -- Sohail Somani http://uint32t.blogspot.com
Robert Ramey wrote:
Sohail Somani wrote:
Just typing out loud: Forward compatibility is the ability to load an archive with a version of 4 into an application with a version of 3.
To me forward compatability is he ability to create a version 3 archive with a version 4 program. Hmmm - now that I read that, it doesn't look right. I guess that should be called "complete" backward compatibility. I don't see how it is possible while writing version 3 progam to know what version 4 is going to save.
See my reply to Steven W. -- Sohail Somani http://uint32t.blogspot.com
participants (5)
-
Brian Wood -
Kenny Riddile -
Robert Ramey -
Sohail Somani -
Steven Watanabe