[
https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077235#comment-17077235
]
Igor Sapego commented on IGNITE-12853:
--------------------------------------
[~alex_pl]
1. I think it's much more readable and understandable for any newcomer. Also,
code like this is easier to fix or change.
2. The same. Many versions were not even labeled in the code, so no one could
find out what kind of changes were introduced by a certain version without
additional research. Now it's much more easy to read, understand and thus
change. Why do you think that numbers comparison is more intuitive?
3. All classes in Java thin client are duplicated, see ProtocolVersion for
example. I believe, initially this was done for Java Thin client to have no
dependencies on core, which looks reasonable and anyway this is not a ticket to
change this approach. For the server-side interface -- this is a good catch, I
belive I should copy it as well.
> ThinClient: Introduce Features for thin clients
> -----------------------------------------------
>
> Key: IGNITE-12853
> URL: https://issues.apache.org/jira/browse/IGNITE-12853
> Project: Ignite
> Issue Type: Bug
> Components: thin client
> Reporter: Igor Sapego
> Assignee: Igor Sapego
> Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
