Hi, I'm working on an atrocious project whereby the persistence/serialization of various objects is done by an internal framework. Data is stored in binary format. Each piece of data is stored with an integer identifier that assicates it with the bindary data. I won't go into the details here. Anyways, this framework is very old and appears to present more problems than it solves. My goal is to convince the project manager that boost serialization is the way to go. They are against external 3rd party libraries despite the fact that boost is maintained by hundreds of developers (perhaps more). If I can provide a persuasive argument to migrating to boost, I can rid this project of a lot of issues. Here's the issues we currently face; A) The objects we persist are very much subject to change. New fields are added, moved around and deleted more or less as the wind blows. With each version of the application, various objects are persisted to disk in a file. This file *must* be compatible with the next version of the application. V1 objects and V2 objects are similar but not always identical (sometimes they are). Migration from V1 to V2 is done by massacring the the codebase with if/else statements. -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-tp3498451p3498451.html Sent from the Boost - Users mailing list archive at Nabble.com.
grahamo wrote:
Hi, If I can provide a persuasive argument to migrating to boost, I can rid this project of a lot of issues.
This is very symple. a) download the boost libraries needed b) to each file, add a newline the end c) At this point they are your files. This is due the the pottery barn rule "you break it you bought it" - which is in force at least for the serialization library. d) Now tell your boss that, inspired by open source efforts, you've made your own improved system which will be proprietary to his company. e) you'll be responsable for maintaining your own version since it's yours but not boosts anymore. But this is one heck of a lot less work than maintaining your current code base. Everyone should be happy with this.
Here's the issues we currently face;
A)
The objects we persist are very much subject to change. New fields are added, moved around and deleted more or less as the wind blows. With each version of the application, various objects are persisted to disk in a file. This file *must* be compatible with the next version of the application. V1 objects and V2 objects are similar but not always identical (sometimes they are). Migration from V1 to V2 is done by massacring the the codebase with if/else statements.
The serialization library addresses this as part of its design. However, I have to confess that I've broken this a couple of times by accident on binary archives. I think I got it all fixed. You might want to convince your boss that using text archives will be more efficient as they take less space. Good Luck Robert Ramey
participants (2)
-
grahamo -
Robert Ramey