search

ably / specification

The Ably features spec for client library SDKs.
Apache License 2.0
0 stars 4 forks source link

Specify API for Ably wrapper SDKs to obtain 'inner' agents components #111

Closed QuintinWillison closed 1 year ago

QuintinWillison commented 1 year ago

As observed in https://github.com/ably/ably-asset-tracking-common/pull/66#issuecomment-1309993388.

It would be useful for Ably wrapper SDKs to be able to obtain a 'rendered', aggregate agents string, matching what the SDK sends to the Ably service.

This needs specifying. It might fit as a new client options API, however - even if static in nature (i.e. a class, not instance, method) - we have nothing similar currently in that API.

sync-by-unito[bot] commented 1 year ago

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-2919

lawrence-forooghian commented 1 year ago

@QuintinWillison did you envisage this just providing the SDK’s baked-in own agents, without the ability to add custom ones to the final output? So, for example, in the case of iOS, it would be an API that returns a string like ably-cocoa/1.2.16 iOS/16.1.0?

lawrence-forooghian commented 1 year ago

As far as I can tell, the feature spec doesn't provide any obvious place to put this sort of introspection. But in ably-cocoa, we have the public ARTDefault, and in ably-java, the public Defaults, both of which already provide non-spec things like access to the library version number. I was wondering how you feel about these interfaces – do you think we should be aiming to replace them with something properly specified?

I was wondering about perhaps creating a new interface designed for introspection of the library, perhaps a SDKInfo class with static methods?

QuintinWillison commented 1 year ago

Method Signature

did you envisage this just providing the SDK’s baked-in own agents, without the ability to add custom ones to the final output?

I don't have strong feelings either way, however it might make most sense for there to be a single chef responsible for aggregate string rendering - therefore, ability to add custom ones (in the same map/dictionary format as expected by client options' agents) might make most sense. 🤔

Method Location

I have sympathy for the desire to spawn a new class (SDKInfo) but I think perhaps it's more of a matter of interpretation of the words being used. Both ARTDefault (Cocoa) and Defaults (Java) are already offering static methods/getters, so I would argue that this class already performs the role of providing "SDK information" in a way that doesn't require a REST or Realtime client to have been instantiated yet, therefore it fits the bill (even if the name isn't precisely to everybody's taste).

There is the slightly wider challenge, also, that there doesn't seem to be any coverage in the features spec of these 'default'/'defaults' utility classes anyway. We'll need to establish a footing for that when working on this issue, clearly.