Igor, great idea, I think this should be our priority for all thin clients.
Alexei, protocol version bump can be still required for major changes (e.g. if we want to change handshake format). But for simpler things like new features that don't affect existing ones, feature masks allow us to keep current protocol version. On Thu, Jan 23, 2020 at 3:55 PM Taras Ledkov <tled...@gridgain.com> wrote: > Alexei, > > After the flags is introduced we can change the flag set instead of > change protocol version. > Of course, we will need to up the protocol version for introducing flags. > > On 23.01.2020 15:47, Alexei Scherbakov wrote: > > Igor Sapego, > > > > I do not understand how feature masks can remove the necessity of having > > protocol versioning. > > A protocol for one feature can change from release to release. > > > > чт, 23 янв. 2020 г. в 15:36, Igor Sapego <isap...@apache.org>: > > > >> Hi Igniters, > >> > >> As we have a lot of different thin clients now, maintained by different > >> people, the issues with our backward compatibility mechanism becomes > >> more and more prominent. > >> > >> Currently, we use protocol versioning as the only approach to provide > >> backward compatibility. The main issue of this approach is that we can > >> not skip some change in protocol and implement i.e. protocol of version > >> 1.5 without implementation of 1.4. There are many cases when one may > >> want to do so: e.g. when feature provided in 1.4 is not relevant for a > >> specific client, or when protocol version 1.5 contains urgent fix or > >> feature > >> which is easy to implement, but its blocked by not-so-urgent and > >> hard-to-implement feature introduced in 1.4. > >> > >> So to fix this issue I propose to introduce another backward > compatibility > >> mechanism. The idea is to send "supported features" mask by a client to > >> a server, which should be answered with the same mask by the server. > >> The resulting set of enabled features is acquired with a simple logical > >> "AND" > >> operation on these two masks. > >> > >> This change has many other positive effects: > >> 1. It improves readability and also potentially simplifies debugging. > >> 2. It gives users the ability to enable or disable features of thin > clients > >> on both > >> server and client as they desire. > >> > >> What are your thoughts guys? > >> > >> Best Regards, > >> Igor > >> > > > -- > Taras Ledkov > Mail-To: tled...@gridgain.com > >
