Add opt-out of implicit attach when subscribing

[lawrence-forooghian]

Add an attachOnSubscribe channel option, which, if set to false, allows users to opt out of the implicit attach that’s triggered by subscribe-ing to channel or presence messages.

The Chat SDK has decided that in its API, subscribing to a room’s messages or presence messages should not trigger a channel attach operation (see decision record). The JS Chat SDK uses private ably-js API to, essentially, call subscribe without triggering an implicit attach. For the Swift and Kotlin SDKs, we’d like to avoid this, hence this new API.

I’m not sure what’s the better approach out of adding a new channel option (I don’t love the fact that we just ignore the user-provided “on attach” callback) or adding a new method called something like subscribeWithoutAttach (which, given that it’d be part of the public API, might be quite confusing for users when it appears in their IDE autocomplete or whatever).

Resolves #202.

[SimonWoolf]

fine by me

[AndyTWF]

LGTM

We should consider whether we want this to be default behaviour in future major SDK versions.

[sacOO7]

Okay noob question, why don't we just create plain channel when subscribe is called.

void subscribe("room1") Channel {
   return new realtimeClient.Channels.Get("room1")
}

This shouldn't send attach message and just create a room instead

[lawrence-forooghian]

Okay noob question, why don't we just create plain channel when subscribe is called.

The aim of subscribe is to register a listener that will be called when the channel receives a message. Your example fetches a channel but doesn't register a listener.

[SimonWoolf]

We should consider whether we want this to be default behaviour in future major SDK versions.

I would endorse this, never liked implicit attach. (especially never liked the asymmetry of 'implicit attach on first subscribe but no implicit detach on last unsubscribe')

[AndyTWF]

We should consider whether we want this to be default behaviour in future major SDK versions.

I would endorse this, never liked implicit attach. (especially never liked the asymmetry of 'implicit attach on first subscribe but no implicit detach on last unsubscribe')

In Chat we took the approach of having subscribe having no bearing at all on the chat room lifecycle (in all cases). Any listener registration is purely synchronous. Similar for any other operation that would have a side effect (e.g. presence get), we either have it behind a promise that won't resolve until attach is initiated explicitly, or it simply fails and informs the user that they need to attach first.

[ttypic]

I like this approach

[maratal]

we just ignore the user-provided “on attach” callback

Maybe do attach when user provides this callback and do not do by default if not?

[lawrence-forooghian]

Maybe do attach when user provides this callback and do not do by default if not?

That'd be a breaking API change — the current expectation is that if you call subscribe then it attaches.

[maratal]

LGTM