Need versioning for serialization

[mdavidsaver]

I see that #24 highlights the lack of any concept of version in the present serialization APIs. At some point (imo #24 almost qualifies) it will be desirable to control the serialization format depending on peer protocol version to avoid backwards incompatible changes.

@msekoranja I'm not sure where this should go. Perhaps in the (de)serialization control interface?

[msekoranja]

One level up, I would say.
In case of pvAccess, pvAccess peers already exchange version (the protocol version, but I would say that pvData serialization is implied), byte-ordering, etc.. In case of using pvData serialization in files, the meta-data should go into a file header.

[mdavidsaver]

One level up, I would say.
In case of pvAccess, pvAccess peers already exchange version ...

And then? I would like to see the serialization API extended so that the outcome of this exchange (or some file) can be passed to serialization code in pvData*. That's why this issue is here instead of pvAccessCPP.

[gregoryraymondwhite]

Right!

On Feb 16, 2016, at 11:35 AM, mdavidsaver notifications@github.com wrote:

One level up, I would say.
In case of pvAccess, pvAccess peers already exchange version ...

And then? I would like to see the serialization API extended so that the outcome of this exchange (or some file) can be passed to serialization code in pvData*. That's why this issue is here instead of pvAccessCPP.

—
Reply to this email directly or view it on GitHub.

[msekoranja]

@mdavidsaver I immediately thought of "(de)serialization control interface". An alternative is to provide version when calling factories of FieldCreate, PVDataCreate. I prefer first idea - adding "uint8_t get_version()" method?

[mdavidsaver]

adding "uint8_t get_version()" method?

Agreed.

For completeness, the only other possibility which occurred to me is as an argument to the de/serialize() methods as with the boost serialization library. However, I don't like this as adding arguments to virtual methods can lead to subtle bugs involving argument list overloading if sub-classes can't be updated at the same time.