Client should be able to check Scratch Link's version

[cwillisf]

Expected Behavior

The client (scratch-vm and other supported clients) should be able to send a request to Scratch Link to check the protocol version number.

For bug/workaround reasons it might be a good idea to also report the application version. On the other hand, for privacy/security reasons, and also to discourage scratch-vm from caring too much about the application version, we might not want to report the application version. To be discussed...

Actual Behavior

Currently the client request any version information from Scratch Link.

[cwillisf]

My opinion on the application version question: let's just do the protocol version as a first pass, and if we find a reason for application version later then we can add it. The main disadvantage of this approach is that we won't have an official way to distinguish different application versions prior to actually adding the field, but my expectation (hope?) is that having the protocol version available will mean we won't run into a situation where the application version matters and so we'll never need to add it to the protocol.

Even so, I would suggestion a version request response structure capable of handling extra fields, for example:

{
  // ...
  "result": {
    "api": "1.2.0",
    "possible-field-for-future-use": "3.1.4"
  }
}

Separately: what should the "protocol version" field be called? I could see arguments for just about any of the following:

• "network-protocol"
• "protocol"
• "scratch-link-protocol"
• "api"

Of course, we can also argue about whether the multi-word options should be camelCase, snake_case, kebab-case, separated with spaces, etc...

CC @ericrosenbaum @evhan55 @knandersen @thisandagain

[evhan55]

One vote for:

• protocol or api for protocol version
• version for app version

But I don't know if there are other standards out there. Anyway I personally prefer short labels when possible if the distinction can be clear enough.