-
Notifications
You must be signed in to change notification settings - Fork 41
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
Token ClientOption should allow Token, TokenDetails or TokenRequest #75
Comments
Optionally a client library should be instanceable with just a TokenDetails object, like we do for API Key string or Token string, where the language permits |
I'm happy with the first (initing with Not sure about the second (initing with just a tokenDetails) -- means in weakly-typed languages we'd have to guess whether an object passed to the constructor is a tokenDetails or a clientOptions. |
No, you only need to check if:
That same logic exists for Not sure why you'd need to determine if its a |
Your're justifying your first proposal (initing with If you instance a client library with an object, currently that's assumed to be a clientOptions (in weakly-typed languages). clientOptions and tokenDetails can both have (I'd have no objection to the second proposal if it applies only to strongly typed languages where there's no need for guesswork) |
👍
I believe that would be the first time we support different things in different kinds of languages. I don't think it's worth it to break it, it's potentially a slippery slope. |
Additionally, we can support it everywhere but define that in JavaScript and friends the argument is considered a TokenDetails or TokenRequest only if |
@SimonWoolf sorry, my comment Sorry for the confusion both. |
👎 TokenDetails and TokenRequest objects in the js lib are currently plain JS objects ducktyped by their properties. There's no prototype. That's probably not something we'd be looking to change at this point - for one thing that's how the js world (especially frontend devs) seems to generally expect things to work, for another that'd move 0.9 from being a technically-breaking change (that will still work for 95% of people with no changes), to being a this-will-definitely-break-your-code change. And for what goal? The only point of being ably to do In any case, we can't use |
Anyway, given Matt's clarification, this is a moot point. We all agree with the original suggestion (#75 (comment)) 🙂 |
Ok, so we are all agreed then :) @SimonWoolf fancy a spec PR? |
Implemented in iOS:
Implemented in Java: Implemented in JS: |
Currently
ClientOption#token
only supports aToken
orTokenDetails
object. It should also support aTokenRequest
givenauthUrl
andauthCallback
both support all threeThe text was updated successfully, but these errors were encountered: