Support optional multiple recovery scopes

[SimonWoolf]

New recoveryScope client option where, if specified, the SDK's recovery key will be persisted under that identifier (in sessionstorage), so only another library instance which specifies the same recoveryScope will attempt to recover from it. This is useful if you have multiple ably-js instances sharing a given origin (the origin being the scope of sessionstorage), as otherwise the multiple instances will overwrite each other's recovery keys, and after a reload they will all try and recover the same connection, which is not permitted and will cause broken behaviour.

Not entirely happy with recoveryScope but I can't think of anything better (considered: recoveryKeyKey, recoveryKeyIdentifier, recoveryDiscriminator, recoveryTag, recoveryMarker, ...)

[ttypic]

Agreed that scope is not perfect. To me, it implies that two clients can share the same scope, which is incorrect. What do you think about name? name should be given and unique, for example, recoveryKeyName.

Also, what do you think about making this feature more general-purpose? For example, clientName or something similar. We can reuse it for other purposes, such as labeling logs. We've received complaints before that if you use more than one client, it's impossible to work with logs.

Lastly, who will be responsible for adding this to the specification?

[SimonWoolf]

Agreed that scope is not perfect. To me, it implies that two clients can share the same scope, which is incorrect. What do you think about name? name should be given and unique, for example, recoveryKeyName.

Maybe. At this point the words "recovery key" have started to glaze over for me so I've made a poll in #topic-engineering to gather opinions.

Lastly, who will be responsible for adding this to the specification?

Features that are specific to ably-js, like sessionstorage persistence on beforeunload, or jsonp, or the comet transport don't typically get added to the spec. (the spec is to ensure consistency of implementations, we've generally taken the view that it's not needed if there's only one implementation)

Also, what do you think about making this feature more general-purpose? For example, clientName or something similar. We can reuse it for other purposes, such as labeling logs. We've received complaints before that if you use more than one client, it's impossible to work with logs.

That is indeed a bug, but the bug is that the logger is global. So we can't add anything a client name to each logger instance, because there are no separate logger instances. Once that bug is fixed, I'm not sure a clientName would be particularly needed -- if we want to add a unique string to each log we can use the connectionId, which has the advantage that it doesn't require any customer action and we can correlate with serverside logs. Or if someone wants something fancier they can pass in a logHandler.

In particular I think we should have a bias against adding new spec'd client options (i.e. options that we want to add to the spec and all sdks) unless we're sure they're justified. They add lots of work for us (getting every sdk into compliance), and that bit more complexity to the customer for someone scanning down a list of options (not to mention the potential for confusion -- clientName vs clientId etc).

[VeskeR]

LGTM overall, would like to re-review once the naming is settled.

[SimonWoolf]

based on the poll results I've gone with recoveryKeyStorageName. Not a fan myself but meh whatever

[SimonWoolf]

@ttypic poke

[ttypic]

Looks good to me!