We should check that it is actually safe to add fields. If it isn't we're likely to have a lot of versioning to do.
-- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 On Mon, Sep 25, 2017 at 5:25 PM, Galen O'Sullivan <gosulli...@pivotal.io> wrote: > Replies inline. > > On Mon, Sep 25, 2017 at 12:13 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> > wrote: > > > Replies inline > > On Mon, Sep 25, 2017 at 11:21 AM, Dan Smith <dsm...@pivotal.io> wrote: > > > > > This actually brings up another point I was going to ask about. I don't > > see > > > any version information in the protocol. How will we handle adding new > > > features to this protocol? Do the clients and servers negotiate which > > > version of the protocol to use somehow? > > > > > > I think there should be a plan in place for making changes to the > > protocol > > > and supporting old clients. Given that, we shouldn't add fields that > > aren't > > > actually used into the existing version of the protocol. When we > > introduce > > > new features into the protocol, that's the point at which we should add > > the > > > fields to support that feature. > > > > > > > [UK] - Protobuf allows for the amending of messages. As soon as the > > protocol changes significantly the "magic" number will have to be > > incremented, indicating a new (non-backward compatible) version of the > > protocol. This of course has bigger problems, where Java does not allow > for > > multiple versions of the same class to be loaded, so a server could run > > only 1 version of Protobuf messages at a time. > > > > We have to be careful about how we extend protobuf messages, though. I'm > not sure exactly what's safe to do, but it should at least be safe to add > fields (assuming they don't change existing behavior -- we'll have to think > about this) and ignore old fields (which is how you would remove a > now-unused field). It's fairly simple to add new operations without any > interesting breakages - they'll fail with older servers and not be sent > with older clients. I think adding new operations is a pretty good way to > add features that don't require a real rework of the protocol. For those > that do, we can version the initial byte. >
