You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Igor Sapego <is...@apache.org> on 2020/01/23 12:36:27 UTC
Feature masks for thin clients
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
Re: Feature masks for thin clients
Posted by Ivan Pavlukhin <vo...@gmail.com>.
> A protocol for one feature can change from release to release.
I think about it in a following way. Imagine that we reworked somehow
affinity awareness and changes are needed on a protocol level. From a
features point of view old feature is AffinityAwarenessV1 and new one
is AffinityAwarenessV2.
> Probably the "feature" word is confusing here. Maybe we should use term "Changes Mask" or something like that.
Bitmask layout seems to be an implementation detail. From a high level
the subject sounds to me more like "Feature set". Client and server
can support different subsets of all features. With feature versioning
term "feature" might be confusing sometimes. But I am not sure that it
is a big problem. Feel free to suggest better naming.
Regarding the necessity of the subject. The main driver for me (it was
already mentioned it the thread) is a simplification of clients for
different languages development. I suppose the community do not have
enough resources to support all features for all languages,
consequently some workaround is needed.
пт, 24 янв. 2020 г. в 19:32, Igor Sapego <is...@apache.org>:
>
> Taras,
>
> I believe we should have the same mechanism but different
> set of flags.
>
> Alexey,
>
> The idea is to add new flag when you make changes instead of
> increment protocol version. This way client maintainer can introduce
> the same change (probably fix) in they client without the necessity to
> implement all other features that were introduced in between.
>
> Probably the "feature" word is confusing here. Maybe we should use
> term "Changes Mask" or something like that.
>
> Best Regards,
> Igor
>
>
> On Thu, Jan 23, 2020 at 5:27 PM Pavel Tupitsyn <pt...@apache.org> wrote:
>
> > 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 <tl...@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 <is...@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: tledkov@gridgain.com
> > >
> > >
> >
--
Best regards,
Ivan Pavlukhin
Re: Feature masks for thin clients
Posted by Igor Sapego <is...@apache.org>.
Taras,
I believe we should have the same mechanism but different
set of flags.
Alexey,
The idea is to add new flag when you make changes instead of
increment protocol version. This way client maintainer can introduce
the same change (probably fix) in they client without the necessity to
implement all other features that were introduced in between.
Probably the "feature" word is confusing here. Maybe we should use
term "Changes Mask" or something like that.
Best Regards,
Igor
On Thu, Jan 23, 2020 at 5:27 PM Pavel Tupitsyn <pt...@apache.org> wrote:
> 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 <tl...@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 <is...@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: tledkov@gridgain.com
> >
> >
>
Re: Feature masks for thin clients
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <tl...@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 <is...@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: tledkov@gridgain.com
>
>
Re: Feature masks for thin clients
Posted by Taras Ledkov <tl...@gridgain.com>.
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 <is...@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: tledkov@gridgain.com
Re: Feature masks for thin clients
Posted by Alexei Scherbakov <al...@gmail.com>.
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 <is...@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
Re: Feature masks for thin clients
Posted by Taras Ledkov <tl...@gridgain.com>.
Hi,
The great idea!
What do you think about thin JDBC and ODBC?
Should we have common feature flags set and client specific feature flag
set?
Or each client has independent flags set even if they are duplicated?
On 23.01.2020 15:36, Igor Sapego wrote:
> 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: tledkov@gridgain.com