You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Dealing with forwards and backwards compatibility is a core consideration in the platform and the protocol.
Currently we have some feature-guarding in the server which is based on the version of the dart client, which the client currently sends with the from verb - e.g. version 3.0.43, or 3.0.57, or etc. Currently we only use this feature in the server to send error responses as json to clients which we know can comprehend json error responses, and plain strings to other clients. In global_exception_handler.dart:
if (Version.parse(atConnection.getMetaData().clientVersion) >Version(3, 0, 37)) {
logger.info(
'Client version supports json encoding.. returning Json encoded error message');
var errorJsonMap = {
'errorCode': errorCode,
'errorDescription': errorDescription
};
atConnection.write('error:${jsonEncode(errorJsonMap)}\n$prompt');
return;
}
As we will have many different client libraries, we need to make this behaviour work for all platforms.
Describe the solution you'd like
atServer should comprehend a new field in the clientConfig json called 'atProtocol'
The value should be set by the client based on what version of the protocol the client understands
Arbitrarily, I've decided that
the current version of the atProtocol as understood by the latest Dart client v3.0.57 is atProtocol version 2.0.0
the previous version was 1.5.0
We should then change the server code snippet above so that clients which state that they are at version 1.5.0 or above, or they are a Dart client at version 3.0.38 or later, will be deemed to understand error responses sent as JSON.
The intention is that, every time we change request or response syntax in the future, we will bump the atProtocol accordingly. There are plenty of other things to consider here and it will evolve in the future but it starts by having the server understand what version of the protocol a client 'understands', and having clients send that information when they issue the from verb
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
Discussed what makes a version change (changes to syntax, new verbs, changed response, etc, anythoing like that)
Dsicsused future things like test suites that verify that an atServer or a client library supports version X.Y.Z of the atProtocol
Is your feature request related to a problem? Please describe.
Dealing with forwards and backwards compatibility is a core consideration in the platform and the protocol.
Currently we have some feature-guarding in the server which is based on the version of the dart client, which the client currently sends with the
from
verb - e.g. version 3.0.43, or 3.0.57, or etc. Currently we only use this feature in the server to send error responses as json to clients which we know can comprehend json error responses, and plain strings to other clients. In global_exception_handler.dart:As we will have many different client libraries, we need to make this behaviour work for all platforms.
Describe the solution you'd like
The intention is that, every time we change request or response syntax in the future, we will bump the atProtocol accordingly. There are plenty of other things to consider here and it will evolve in the future but it starts by having the server understand what version of the protocol a client 'understands', and having clients send that information when they issue the
from
verbDescribe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: