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.
