REST and Realtime Statistics (Stats) #106
Labels
blocked-by-ably
We can't proceed until something under our direct control, in a different codebase, happens.
enhancement
New feature or improved functionality.
Comments
QuintinWillison
changed the title
|
I think |
Closed
|
➤ Igor Kurek commented: Blocked for the same reason as https://ably.atlassian.net/browse/SDK-1385 ( https://ably.atlassian.net/browse/SDK-1385|smart-link ) |
|
blocked untill ably/ably-java#733 and ably/ably-cocoa#1284 are resolved |
lawrence-forooghian
added a commit
to ably/docs
that referenced
this issue
Jun 9, 2022
My initial motivation here is EDX-175. We want the entire public API of our SDKs to have docstring comments. We will be approaching this by using this spec’s IDL as our source of truth for what constitutes our SDK’s public API, to which tech writers will then add generic descriptive comments. Hence, the IDL will need to contain the stats-related types, which it currently doesn’t. The first step towards achieving this is to make sure that all of these types are documented in the spec. Currently, the types are not documented, instead pointing the reader towards the Ruby documentation. I don’t think it makes sense for a generic feature spec to refer to a specific implementation as a reference - seems a bit circular, and requires the reader to have at least a passing knowledge of that language. Furthermore, it means that there’s a chunk of the feature spec that won’t go through the usual feature spec review process - any changes to that part of the Ruby SDK will become changes to the feature spec, without the Ruby SDK developers necessarily even realising this. Also, at the time of writing, the Ruby SDK generated documentation was broken, not displaying any classes at all (all of the links currently in the feature spec giving 404s). The lack of stats documentation has also caused us to be blocked on ably/ably-flutter#106 (adding stats functionaity to the Flutter SDK), because of inconsistencies between ably-cocoa and ably-java which the current documentation was not sufficient to help us resolve. The information and comments that I’ve added here are taken from ably-ruby@f5eac15. I’ve lightly edited the descriptions, but I think they still could be improved a lot. I think I’ll need input from someone with more knowledge of what the numbers in the stats response actually mean, though. There are a couple of types mentioned in the spec which are not actually implemented in the Ruby SDK – PushStats and XchgMessages. I’ll handle those separately.
lawrence-forooghian
added a commit
to ably/docs
that referenced
this issue
Jun 9, 2022
My initial motivation here is EDX-175. We want the entire public API of our SDKs to have docstring comments. We will be approaching this by using this spec’s IDL as our source of truth for what constitutes our SDK’s public API, to which tech writers will then add generic descriptive comments. Hence, the IDL will need to contain the stats-related types, which it currently doesn’t. The first step towards achieving this is to make sure that all of these types are documented in the spec. Currently, the types are not documented, instead pointing the reader towards the Ruby documentation. I don’t think it makes sense for a generic feature spec to refer to a specific implementation as a reference - seems a bit circular, and requires the reader to have at least a passing knowledge of that language. Furthermore, it means that there’s a chunk of the feature spec that won’t go through the usual feature spec review process - any changes to that part of the Ruby SDK will become changes to the feature spec, without the Ruby SDK developers necessarily even realising this. Also, at the time of writing, the Ruby SDK generated documentation was broken, not displaying any classes at all (all of the links currently in the feature spec giving 404s). The lack of stats documentation has also caused us to be blocked on ably/ably-flutter#106 (adding stats functionality to the Flutter SDK), because of inconsistencies between ably-cocoa and ably-java which the current documentation was not sufficient to help us resolve. The information and comments that I’ve added here are taken from ably-ruby@f5eac15. I’ve lightly edited the descriptions, but I think they still could be improved a lot. I think I’ll need input from someone with more knowledge of what the numbers in the stats response actually mean, though. There are a couple of types mentioned in the spec which are not actually implemented in the Ruby SDK – PushStats and XchgMessages. I’ll handle those separately.
lawrence-forooghian
added a commit
to ably/docs
that referenced
this issue
Jun 13, 2022
My initial motivation here is EDX-175. We want the entire public API of our SDKs to have docstring comments. We will be approaching this by using this spec’s IDL as our source of truth for what constitutes our SDK’s public API, to which tech writers will then add generic descriptive comments. Hence, the IDL will need to contain the stats-related types, which it currently doesn’t. The first step towards achieving this is to make sure that all of these types are documented in the spec. Currently, the types are not documented, instead pointing the reader towards the Ruby documentation. I don’t think it makes sense for a generic feature spec to refer to a specific implementation as a reference - seems a bit circular, and requires the reader to have at least a passing knowledge of that language. Furthermore, it means that there’s a chunk of the feature spec that won’t go through the usual feature spec review process - any changes to that part of the Ruby SDK will become changes to the feature spec, without the Ruby SDK developers necessarily even realising this. Also, at the time of writing, the Ruby SDK generated documentation was broken, not displaying any classes at all (all of the links currently in the feature spec giving 404s). The lack of stats documentation has also caused us to be blocked on ably/ably-flutter#106 (adding stats functionality to the Flutter SDK), because of inconsistencies between ably-cocoa and ably-java which the current documentation was not sufficient to help us resolve. The information and comments that I’ve added here are taken from ably-ruby@f5eac15. I’ve lightly edited the descriptions, but I think they still could be improved a lot. I think I’ll need input from someone with more knowledge of what the numbers in the stats response actually mean, though. There are a couple of types mentioned in the spec which are not actually implemented in the Ruby SDK – PushStats and XchgMessages. I’ll handle those separately.
QuintinWillison
pushed a commit
to ably/specification
that referenced
this issue
Sep 20, 2022
My initial motivation here is EDX-175. We want the entire public API of our SDKs to have docstring comments. We will be approaching this by using this spec’s IDL as our source of truth for what constitutes our SDK’s public API, to which tech writers will then add generic descriptive comments. Hence, the IDL will need to contain the stats-related types, which it currently doesn’t. The first step towards achieving this is to make sure that all of these types are documented in the spec. Currently, the types are not documented, instead pointing the reader towards the Ruby documentation. I don’t think it makes sense for a generic feature spec to refer to a specific implementation as a reference - seems a bit circular, and requires the reader to have at least a passing knowledge of that language. Furthermore, it means that there’s a chunk of the feature spec that won’t go through the usual feature spec review process - any changes to that part of the Ruby SDK will become changes to the feature spec, without the Ruby SDK developers necessarily even realising this. Also, at the time of writing, the Ruby SDK generated documentation was broken, not displaying any classes at all (all of the links currently in the feature spec giving 404s). The lack of stats documentation has also caused us to be blocked on ably/ably-flutter#106 (adding stats functionality to the Flutter SDK), because of inconsistencies between ably-cocoa and ably-java which the current documentation was not sufficient to help us resolve. The information and comments that I’ve added here are taken from ably-ruby@f5eac15. I’ve lightly edited the descriptions, but I think they still could be improved a lot. I think I’ll need input from someone with more knowledge of what the numbers in the stats response actually mean, though. There are a couple of types mentioned in the spec which are not actually implemented in the Ruby SDK – PushStats and XchgMessages. I’ll handle those separately.
QuintinWillison
added
blocked-by-ably
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The absence of this feature is a known limitation of this plugin.
See:
Statsobject and its attributesRestClientfunctionstatsReatimeClientfunctionstatsThe text was updated successfully, but these errors were encountered: