Add spec points to describe the Objects plugin
#332
Conversation
textile/features.textile
Outdated
| * @(PC2)@ No generic plugin interface is specified, and therefore there is no common API exposed by all plugins. However, for type-safety, the opaque interface @Plugin@ should be used in strongly-typed languages as the type of the @ClientOptions.plugins@ collection as per "TO3o":#TO3o. | ||
| * @(PC3)@ A plugin provided with the @PluginType@ enum key value of @vcdiff@ should be capable of decoding "vcdiff"-encoded messages. It must implement the @VCDiffDecoder@ interface and the client library must be able to use it by casting it to this interface. | ||
| ** @(PC3a)@ The base argument of the @VCDiffDecoder.decode@ method should receive the stored base payload of the last message on a channel as specified by "RTL19":#RTL19. If the base payload is a string it should be encoded to binary using UTF-8 before being passed as base argument of the @VCDiffDecoder.decode@ method. | ||
| * @(PC5)@ A plugin provided with the @PluginType@ enum key value of @Objects@ should provide the "RealtimeObjects":#RTO1 feature functionality for realtime channels. It must implement the @ObjectsPlugin@ interface and the client library must be able to use it by casting it to this interface. |
There was a problem hiding this comment.
In case of ably-java, just including liveobjects dependency using
implementation 'io.ably:ably-liveobjects:1.2.52'
detects the plugin at runtime ( We don't need to supply it as a part of options )
So, not sure if this spec needs to be modified or can be made optional
There was a problem hiding this comment.
The current spec does not reflect the plugins systems implemented in other languages indeed, as that is a new addition. Plugins system only existed in ably-js until recently, so we should update the spec based on the decisions we made for ably-java and ably-cocoa
(on a separate note, the plugin should be called objects, not liveobjects , see https://ably.atlassian.net/wiki/spaces/LOB/pages/3819896841/LODR-033+Isolating+API+naming+from+Product+naming+Renaming+state+and+liveobjects+to+objects+in+APIs)
| ** @(RTP15f)@ If the client is identified and has a valid @clientId@, and the @clientId@ argument does not match the client's @clientId@, then it should indicate an error. The connection and channel remain available for further operations | ||
|
|
||
| h3(#objects). Objects | ||
| h3(#realtime-objects). RealtimeObjects |
There was a problem hiding this comment.
| h3(#realtime-objects). RealtimeObjects | |
| h3(#realtime-objects). LiveObjects |
It seems like we're currently using two different terms for the same feature.
To avoid confusion, calling this as LiveObjects would be more consistent naming wdyt?
Unless, LiveObjects is already being used elsewhere and could cause a naming conflict.
There was a problem hiding this comment.
the name of the feature is Objects, and it must not be called LiveObjects in the client library imlpementation at all, see https://ably.atlassian.net/wiki/spaces/LOB/pages/3819896841/LODR-033+Isolating+API+naming+from+Product+naming+Renaming+state+and+liveobjects+to+objects+in+APIs.
The spec change from Objects to RealtimeObjects this PR adds is explained in commit message ccc5329, but essentially it's to keep consistency with RealtimeChannels, RealtimePresence, and allow us to add RestObjects in the future.
This change only relates to the name of the public class exposed to the end-user. It does not change the property found on a channel: channel.objects returns a RealtimeObjects instance, just like channel.presence returns RealtimePresence
There was a problem hiding this comment.
Thanks, will take a look at LODR 👍
lawrence-forooghian
left a comment
lawrence-forooghian
left a comment
There was a problem hiding this comment.
A few suggestions, but I don't think we need to spend too long on this PR; we understand that the plugins mechanism is going to vary by implementation and I don't think we need to be exhaustive.
… with the naming convention for other realtime features in the SDK This updates ably-js implementation to match the spec [1] [1] ably/specification#332
Based on the spec added in [1] [1] ably/specification#332
Per [1] and [2]. [1] ably/specification#332 [2] ably/ably-js#2043
Per [1] and [2]. Resolves #15. [1] ably/specification#332 [2] ably/ably-js#2043
Per [1] and [2]. Resolves #15. [1] ably/specification#332 [2] ably/ably-js#2043
Based on the spec added in [1] [1] ably/specification#332
Also renames feature spec for `Objects` to `RealtimeObjects`. In the future we may add the REST API support for Objects, and it is only reasonable to name that `RestObjects`. To stay consistent with the namings for other features (e.g. RestChannels - RealtimeChannels) we should rename the spec for `Objects` to `RealtimeObjects`
… with the naming convention for other realtime features in the SDK This updates ably-js implementation to match the spec [1] [1] ably/specification#332
… with the naming convention for other realtime features in the SDK This updates ably-js implementation to match the spec [1] [1] ably/specification#332
… with the naming convention for other realtime features in the SDK This updates ably-js implementation to match the spec [1] [1] ably/specification#332
… with the naming convention for other realtime features in the SDK This updates ably-js implementation to match the spec [1] [1] ably/specification#332
… with the naming convention for other realtime features in the SDK This updates ably-js implementation to match the spec [1] [1] ably/specification#332
… with the naming convention for other realtime features in the SDK This updates ably-js implementation to match the spec [1] [1] ably/specification#332
… with the naming convention for other realtime features in the SDK This updates ably-js implementation to match the spec [1] [1] ably/specification#332
… with the naming convention for other realtime features in the SDK This updates ably-js implementation to match the spec [1] [1] ably/specification#332
No description provided.