> 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.
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
implemen
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 c
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 nece
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 :
> Hi Igniters,
>
> As we have a lot of different thin clients now, maintained by di
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 differ
