Well we would be adding messages that current protocol handlers may not know how to deal with which will likely require them to rewrite their code. That being said it would be easier to define a new protocol, even if it is just an extension and then older clients can still deal with the current protocol, and newer clients can request the newer protocol.
On 29 December 2015 at 16:19, Kevin Wooten <kdubb@me.com> wrote:
Ok well if you define as new protocol as any change, regardless of backwards compatibility, then yes. I would define a “new protocol” as something that has breaking changes with a previous version or at the very least a known deviation from existing behavior.
Extending the protocol with some “well-defined” notifications (using the system that is already well-defined) is not something I would consider a new protocol.
I guess like you suggested we’re talking about the semantics of a “3.1” versus “4.0”. I’m looking for mostly “3.1” type of stuff.
> On Dec 29, 2015, at 2:08 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote: > >> So maybe they all are fairly easily implementable in the current protocol? > > New messages => new protocol. > > For instance "schema_notification" message need to be well-defined, > thus it deserves its own entry in the protocol documentation. > Doesn't it? > Vladimir
