-
Notifications
You must be signed in to change notification settings - Fork 55
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
Spec validation #43
Comments
Matt to put a spreadsheet together based on current test status |
Finished reviewing ably-js against the spec. Marked WIPs when I believe something should work but there's no test for it, but not guaranteeing all the wips until there are tests. Here's list of everything I marked 'no' against, broadly sorted into: non-matching names, missing functionality, and non-matching functionality: (while most things on the lists are bugs, I don't want to assume that every variance from the spec is a bug -- eg while the spec says that Wrong names for things
Missing functionality (in roughly descending order of importance)
Behaviour that doesn't match the spec (in roughly descending order of importance)
|
Thanks @SimonWoolf
These have no methods and therefore for JS I don't think creation of distinct types is necessary. Particularly for
I'm pretty sure we decided that this was not appropriate, as there is no guarantee that the corresponding
That seems to have been unilaterally changed when the spec was written. There is no sense in these being different in the API and the protocol.
I think this is an area where there will legitimately be differences between languages. IMO this seems more natural for a dynamic language, but
Again, probably we now need to support both. |
I agree with @paddybyers on this, I don't think types are necessarily needed. With Ruby, we do the same, and often interchangeably allow simple hashes.
I do recall discussing this, but thought we had decided that
Yes, it seems to have been, shame it was not picked up sooner though as everyone has been working to this.
I would agree with @paddybyers on this one, I think it's perfectly valid, especially for the logger, for it to be different based on the language implementation. For example, Python has a completely different way of approaching logging, so we support the idiomatic way instead.
Fine, so long as the documented API of subscribe & unsubscribe is supported. However @paddybyers, if in future we introduced a normal EventEmitter on the Presence object for presence state changes, this could present problems for the Javascript API if we leave |
Thanks @SimonWoolf for doing this! |
This has been implemented for a while: |
This requirement is unclear. What does the callback expect? Simple success/failure, or does the given callback get added as a |
Oops. Sorry, yes - don't know why I marked TO3e 'no' when I marked RTC1b and RTN3 (the other specs relating to autoConnect) 'wip'. Fixed.
Good point. FWIW, current ably-ruby behaviour seems to be to call the callback for the first state change (only) after the Possibly a common case will be devs who won't care about the details of our connection retrying, but just want to know if either they're connected or it's irrecoverably failed, so maybe behaviour that calls back if |
This is in fact a bug the Ruby library, and I should fix it. That was not the intention.
I would agree, providing a callback should simply be called when the intended state is reached, or the intended state will no longer be reachable without intervention i.e. if the state becomes |
See ably/ably-js#43 (comment) As we have not agreed the spec, and it is not a core feature, deferring this until 0.9
@SimonWoolf FYI, my view on the issues is that other than the following, we should probably try and address this over the coming week or two:
|
See ably/ably-js#43 (comment) As we have not agreed the spec, and it is not a core feature, deferring this until 0.9
For version 0.8 of our client libraries, we have a documented specification at http://docs.ably.io/client-lib-development-guide/features/
It is required that all of our client libraries that use a 0.8.x version number, where possible, adhere to this specification ensuring feature compatibility across all languages and platforms. To ensure that we do not have regressions in future from this specification, all of the features within the 0.8 spec should have a matching test as well.
Please can you review this library against the feature set and do the following:
The text was updated successfully, but these errors were encountered: