-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a way to communicate agent information using an existing Realtime instance #201
Comments
@lawrence-forooghian @umair-ably @ttypic - how do we move this forward? could one of you own putting together a proposal around how we will address this? once we have this agreement we can then open the tickets in the relevant SDKs I have created https://ably.atlassian.net/browse/ECO-4958 which one of you can assign yourselves to |
Thanks @jamienewcomb! @lawrence-forooghian and @umair-ably it will be great if one of you can pick up this later, we can discuss this on the next planning, I added my thoughts to the jira ticket comments |
Adding @ttypic’s comment here to keep all discussion in this issue:
|
I’ve looked into it some more, and it seems like the Chat SDK’s approach to analytics is a copy of that of the Spaces SDK. That is, these wrapper SDKs:
The decision records that led to this behaviour seem to be:
Things I’m not sure of re current behaviour
AssumptionsI’ll assume the following, but need to be corrected if there are essential product requirements that these assumptions violate:
Proposal
If people are happy with this approach, then I’ll also create an SDK decision record in order to record this as our decided approach to analytics for wrapper SDKs. |
I don't think this was the intention, no. I think the original requirements of being able to attribute connections to the Spaces SDK were from before we changed the API so that Spaces didn't initialise its own client and thus no longer "owned" the connection, which is why we subsequently added the agent channel param so that we could attribute attachments to the SDK, and then indirectly the connections those attachments belong to.
I don't think the Spaces SDK should be mutating the agents field on the client options, although it should be able to add the agent to REST requests it is responsible for initiating. |
I'm with Lewis on this one. For Chat we just followed what Spaces did, but from a data quality point of view, we only want requests actually made by Chat to show up as such. So a parameter to that effect on the REST |
Internal RFC currently in review for this. |
We don’t have a proper solution for analytics yet ([1] is on hold and has been removed from mobile beta scope), but in a conversation in the team we decided that we might as well at least keep the `agent` channel parameter, which will give us information about channel attaches. So, name it in line with the JS SDK, which uses "chat-js"; i.e. use the name of the programming language, not the platform. [1] ably/specification#201
We don’t have a proper solution for analytics yet ([1] is on hold and has been removed from mobile beta scope), but in a conversation in the team we decided that we might as well at least keep the `agent` channel parameter, which will give us information about channel attaches. So, name it in line with the JS SDK, which uses "chat-js"; i.e. use the name of the programming language ("ios" is misleading since we might be running on macOS or tvOS). [1] ably/specification#201
Background
This arose in the context of ably/ably-chat-swift#18.
We currently have an
agents
client option (RFC7d6) but when this was created our non-core SDKs (e.g. Asset Tracking) were following a pattern in which said SDK would itself instantiate aRealtimeClient
object, populating theagents
client option with information about said SDK. These days, we follow (e.g. in Spaces and Chat) a different pattern in which the user of the SDK instantiates aRealtimeClient
object.The JS Chat SDK has "solved" this problem by using private API to access the private
options
property of the realtime client and then mutating these options’agents
property. For the Swift and Kotlin Chat SDKs, I would like us to instead be able to use an API that’s properly specified in this spec, even if marked as "experimental and for Ably-authored SDKs" only.Requirements
From this internal Slack conversation with @AndyTWF, it sounds like the key requirement is that there be a way to instruct a given
RealtimeClient
instance to append a value to theAbly-Agent
header that is sent when the client makes REST requests via the#request
method.Non-requirements?
From the aforementioned conversation with Andy, it sounds like the following are not needed at least for Chat:
Ably-Agent
header that’s sent when a WebSocket connection is established to Ably (for tracking realtime Chat usage, it sounds like channel params are used instead)but we need to confirm this with whoever is making use of this agent information (@ruimffl I think?)
Some things that might work for now
Ably-Agent
header itself, usingClientInformation.agentIdentifier
(CR3), and then pass this header in#request
’sheaders
param. We’d need to make sure that we specified that a user-specifiedAbly-Agent
header overrides that added by the SDK.agents
argument to#request
.Scope of the mutation
Ideally, the above would actually read "when the client makes certain REST requests via the
#request
method"; that is, we don’t want to add this header to requests that the user issues through theRealtimeClient
object.┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: