On Sunday, 18 August 2013 at 20:33:01 UTC, Jonathan M Davis wrote:
On Sunday, August 18, 2013 21:45:59 Jacob Carlborg wrote:
If versioning is crucial it can be added.
I don't know if it's crucial or not, but I know that the Java
guys didn't have
it initially but ended up adding it later, which would imply
that they ran
into problems that made them decide that it should be there.
I'd certainly be
inclined to think that it's better to have it, and it's
probably easier to add
it before it's merged than later. But I don't know how crucial
it is.
- Jonathan M Davis
I think this versioning idea is more important for protocol
buffers, msgpck, thrift like libraries that use a separate IDL
schema and IDL-compiled code. std.serialization uses the D code
itself to serialize so the version is practically dictated by the
user. It may as well be manually handled....as long as it
throws/returns error and doesn't crash if one tries to
deserialize an archive type into a different/modified D type.
From memory the Protocol Buffers versioning is to ensure schema
generated code and library are compatible. You get compile errors
if you try to compile IDL generated code with a newer version of
the library. Similarly you get runtime errors if you deserialize
data that was serialized with an older version of the library.
This is all from memory so I could be wrong...
Orange seems/feels more like the BOOST.serialization to me but
much better. It's D for a start and allows custom archive types.
In BOOST, the library stores a version number in the archive for
each class serialized. This number defaults to 0 but can be set
by the user via a #define.
http://www.boost.org/doc/libs/1_54_0/libs/serialization/doc/tutorial.html#versioning
I think adding it later can be done without breaking existing
API, if it is deemed necessary. It just needs to default to 0 or
something similar when missing from an archive and ensure it
won't clash with any fields in existing archives.
