microsoft
Supported protocol versions as part of handshake
Today, when the IDE connects to MTP server, it sends its client name and client version, and MTP responds with its server name (test-anywhere) and server version.
To me, those versions are versions specific to the client/server, and not part of the protocol. They should mostly be used to account for "bugs"/"behaviors" of a specific version of a client/server. But those two versions are not aligned together.
I propose to have an array of "supported protocol versions" that both the client and the server exchange. The highest common version is then used by each component. If no such version is found, then the two components are not compatible.
This allows us to make protocol changes easily.
Both the client and the server should assume that the supported protocol versions is "1.0.0" if this information isn't sent by the other side.
This would work, but the protocol is modeled after LSP that specifically dropped this approach in v3 of the protocol in favor of using capabilities. To me both approaches (version, & capabilities) make sense. Because the version can more succinctly represent the required capabilities (a baseline) that each side has to implement to be compliant.
I think the version approach works well for us, and I would also like both sides to still keep posting their server name, and server version. This allows us to do all this (versions and names are fake):
-
client in VS 17.15 has a bug we did not notice, it claims to support protocol 1.8.0, but actually acceptColoredException capability is broken, it requires extra ">>>" at the beginning of the exception. MTP can apply fix specific to the VS client 17.15 to support it until most users migrate off of it to 17.16.
-
MTP side that we ship as nuget can support 2 or 3 versions of protocol that don't have to be sequential, making sure that it can stay compatible with previous version of VS if needed, so extension authors can keep using the latest MTP, and users can use VS / dotnet sdk that is stable, or latest preview.
-
VS Side (client) would have a long list of supported protocol versions, probably because it needs to stay backwards compatible.
q:
-
when we support multiple protocol versions, how do we communicate to the other side which capability belongs to which version? We don't want to always check version + capability. E.g. my client implemented 1.1.0 protocol, and did not implement the optional ICanHaveCheeseBurger capability. In 1.2.0 that capability is now required. We handshook 1.1.0, how do I know if ICanHaveCheeseBurger is supported by the client or not?
-
when capability becomes part of the baseline, the other side would not send it when then support just that, will we have to keep a list of protocol versions and their basline capabilities?
