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 > -- Best regards, Alexei Scherbakov
