Hi Dmitriy,
It is very common practice to keep client protocol compatible with multiple
versions of the server. We constantly face this in practice. I do not see
any reason to drop or complicate this functional: user just connects to the
server and we automatically negotiate on the best feature se
Igor,
I am sorry it took me a while to fully understand your reasoning.
“Update user software first, then update the server” approach still
looks somewhat weird to me (I think of Let's Encrypt client as an
example of “normal” approach in Python world), but since this approach
is vivid, I just hav
The approach you suggest looks to me pretty much the same as installing
a new version of client software in C++ or Java. The issue here that we
break
existing installed software and require for user to update software in order
to have ability to connect to a server. Just imagine that application wh
Igor,
Thank you for your explanation. I think the matter begins to clear up
for me now.
The backward compatibility issue you described can not be applied to
Python, because Python applications, unlike Java ones, do not have to
be built. They rely on package manager (pip, conda, et c.) to run
anyw
Hi,
Well, this approach was used for quite some time in ODBC and JDBC,
so thin client has just inherited it, as we have the same port and the
same handshake message header. Maybe that's why you could not find
any mention of versioning in thin client context.
3. Let's start from this point as this
Hello fellow igniters!
I recently started reconnaissance before the
implementation of IEP-23 [1] in Python thin client. I think it is an
interesting and much promising feature. As I understand, the changes
associated with this feature will result in a new version of the binary
protocol.
What both
