Add SDK variant to be reported when connecting to Ably

[kavalerov]

We need to be ably to see in our data how many users are using Flutter sdk, and right now this information is not being reported as Flutter plugin is just a wrapper around native libraries. I believe we are ably to specify variant via public interface on the native SDK level - lets add a flutter specifier there so we can at least start seeing number of Flutter users right now.

This is a short term fix, long term fix will be support for reporting multiple layers of versions ably/docs#1034

┆Issue is synchronized with this Jira Uncategorised by Unito

[kavalerov]

@QuintinWillison I have created this issue as a follow up to our discussion yesterday. I am not sure what are the details of the implementation - can you please groom the issue?

[QuintinWillison]

The native implementations (ably-cocoa and ably-java) present in the form android-1.2.5 and cocoa.ios-1.2.3 (based on latest versions at the time of writing this). See: internal message with "sample of client agents, versions and variants" for further detail on that.

I think we could consider adding a new interface to the Cocoa and Java libraries that allows a prefix to be added. We'll need to consider whether this new interface should be somehow hidden or becomes part of the published API for these libraries (which itself may be as distinct from published and documented!).

The simplest form would be flutter so we would present flutter-android-1.2.5 and flutter-cocoa.ios-1.2.3 respectively, with perhaps the - separator hard-coded on the native library side. The problem here is that this wouldn't convey the version of the Flutter plugin.

We could upgrade that form to also include the Flutter plugin version but I would start to worry about that in terms of how it intersects with semantic versioning. Right now, for example, we're still in preview so the prefix - were it to match existing forms - would look like flutter-1.2.0-preview.1, meaning we would present flutter-1.2.0-preview.1-android-1.2.5 and flutter-1.2.0-preview.1-cocoa.ios-1.2.3 respectively.

I know @mattheworiordan had some concerns around cardinality in respect of unrelated downstream systems at the backend, so not sure if that upgraded form would be acceptable.

What do people think? @paddybyers? @SimonWoolf? @owenpearson? @kavalerov?

All of the above, of course, assumes that we continue to work this based on a single presented string. We have discussed elsewhere making it more User-Agent-like, which might present better structure than the simplistic extensions I present above, but then might hit the issues Matt is concerned about. Alternatively, of course, might there be scope for us to look at adding a new field / header at point of connection? I guess, we also need some focus on what we're actually trying to solve - which, as I understand it, is better visibility around which client library implementations are active "in the wild".

[owenpearson]

@QuintinWillison Have you had a read through the comments in the proposed spec change here? To summarise the initial idea was to send the core runtime version of an SDK as a custom header but @lmars made the suggestion to use a User-Agent style string (as you also suggested in the above comment). My current intention is to go with the idea in @paddybyers latest comment in that thread (just use the User-Agent header or X-Ably-User-Agent where that's not possible). I'm happy to update that PR accordingly today and try and get it through if that would help with this issue?

[QuintinWillison]

Ah, yes, thanks for that. I knew there had been a discussion elsewhere also.

[QuintinWillison]

I notice that we had already opened an issue for this: #71.

[kavalerov]

@jamienewcomb @QuintinWillison lets include this in the next release of ably-flutter, as we shouldn't release new stuff before we can actually see the outcome (in terms of adoption)

[tiholic]

@QuintinWillison I think the native packages should extend support for customizing Ably-Agent header, to which we can pass flutter as a value. Right?

cc: @kavalerov

[kavalerov]

Yeah, I think it first has to be implemented in ably-java and ably-cocoa (also cc: @owenpearson )

[QuintinWillison]

Hi @tiholic - that's correct, yes. @owenpearson has created tickets for these in the native client library repositories:

• Implement RSC7d (Ably-Agent header) ably-cocoa#1111
• Implement RSC7d (Ably-Agent header) ably-java#665

[QuintinWillison]

This issue has ultimately been replaced by #100.