[
https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077263#comment-17077263
]
Aleksey Plekhanov commented on IGNITE-12853:
--------------------------------------------
# I see no difference in readability between {{isUserAttributesSupported()}}
and {{isFeatureSupported(USER_ATTRIBUTES)}}, but the second approach doesn't
require code duplication.
# Again, version comparison was always in the context of some feature, there
is no need for research. At least if you want to use features here, you should
introduce something like features bounded to versions (not bounded to feature
mask), in this case, you can use 'if !isFeatureSupported(MY_FEATURE) then error
"version MY_FEATURE.version() required', but not 'if isMyFeatureSupported()
then error "version x.x.x required"'
# Initially, thin client implementation always has dependencies on core. All
marshalling/unarshalling routine can't be done without core. Some of core
classes even exposed to thin client public API (see queries). I see no reason
why can't we use enum which was created for thin clients in thin client
internal API and why we should duplicate code instead.
> 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)
