Auth differences between ably-js and ably-ruby

[SimonWoolf]

• if you call request_token with a single argument (normally takes both auth_options and token_params), ably-ruby assumes it's the auth_options, ably-js assumes it's tokenParams.
• if you supply tokenParams, ably-js assumes they replace existing token params, ably-ruby merges them.

@mattheworiordan @paddybyers

(I marginally prefer ably-ruby behaviour in both cases: for the first, having tokenOptions sometimes be the second argument and sometimes be the first seems nonideal; for the second, someone might want to modify the ttl, but would still assume it'd use the clientId the lib was initialized with).

[mattheworiordan]

I agree ;)

[paddybyers]

I agree on the second point, not sure I agree on the first :)

[mattheworiordan]

@paddybyers, the requestToken behaviour that expects authOptions as the first param and tokenParams as the second, but tokenParams as the first if only one arguments is provided is very much a Javascript way of doing things. If authOptions were indeed "inferior", then they should have been the second argument so that we can avoid this ambiguity. I vote we change it and keep the argument ordering consistent across all languages, thoughts?

[paddybyers]

If authOptions were indeed "inferior", then they should have been the second argument so that we can avoid this ambiguity.

Yes, agreed.

I vote we change it

"it" is the precedence (ie match how Ruby prefers authOptions) or the argument order?

I do think that authOptions is inferior, because when you're requesting a token you're primarily, I think, expecting to pass the params relating to that specific token, ie tokenParams. I think authOptions is subsidiary and is only there as a convenience for values that differ from/augment the options given at initialisation. I'm not sure, however, that it is worth changing the argument order at this stage.

[mattheworiordan]

Superseded by #137