-
Notifications
You must be signed in to change notification settings - Fork 127
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
Documentation for new code generator tags, august2024 #1727
Conversation
|
* It is supported to send JSON-RPC over COM-RPC using the 'IDispatch' interface without the need for serialization. | ||
* This is particularly useful for out-of-process (OOP) and remote plugins. | ||
|
||
* The JSON-RPC generator now supports the usage of nested "plain-old data"(POD) types (such as plain C structs) in the C++ interface. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also nested PODs are supported
docs/plugin/interfaces/interfaces.md
Outdated
|
||
* It is now possible to specify a separate JSON-RPC interface for handling connection issues and correct session management, and this will bring more options when the JSON-RPC interface deviates from the COM-RPC interface. | ||
|
||
* It is supported to send JSON-RPC over COM-RPC using the 'IDispatch' interface without the need for serialization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?
docs/plugin/interfaces/interfaces.md
Outdated
* The JSON-RPC generator now supports the usage of nested "plain-old data"(POD) types (such as plain C structs) in the C++ interface. | ||
* The JSON-RPC generator can now parse these structs and their usage in methods and generate a JSON-RPC interface for such cases. | ||
|
||
* `Core::hresult` is required as a return type value of all JSON-RPC enabled interfaces. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?
@@ -76,6 +76,165 @@ By default, when the `@json` tag is added, all methods in the COM-RPC interface | |||
|
|||
In older Thunder versions (<R4), JSON-RPC interfaces were defined using separate JSON schema files. These would then need to be manually wired up in the plugin. By using the code-generators, we can eliminate this step, making it much faster and easier to write plugins. It is no longer recommended to create JSON schema files for JSON-RPC interfaces. | |||
|
|||
#### Overview |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should also document that fixed size arrays are now supported (e.g. array[10], it is used in the new examples below) in certain cases.
We haven't yet documented although it was already possible but guess we should add it now that you can also use variable lenght arrays (so also for json rpc) : https://github.com/rdkcentral/ThunderInterfaces/blob/a229ea291aa52dc99e9c27839938f4f2af4a6190/interfaces/IDisplayInfo.h#L101
docs/plugin/interfaces/tags.md
Outdated
@@ -106,6 +106,8 @@ Ddefines a literal as a known identifier (equivalent of `#define` in C++ code) | |||
|[@interface](#interface)| Specifies a parameter holding interface ID value for void* interface passing | | Yes | No |Method paramter| | |||
|[@length](#length)|Specifies the expression to evaluate length of an array parameter (can be other parameter name, or constant, or math expression)| | No | Yes | Method Parameter| | |||
|[@maxlength](#maxlength)|Specifies a maximum buffer length value | | No | Yes |Method parameter| | |||
|[@default](#default)|Provides a default value for an unset optional type | | Yes | Yes |Method parameter| | |||
|[@encode:base64](#encode:base64)|Encodes C-Style arrays as JSON-RPC base64 arrays | | Yes | Yes |Method parameter| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be in line with the above documentation think the base64 should not be here but just document #encode influences the generated encoding and list the options (so also bitmask, see Sebastians presentation ) where the details are documented (so more like @text is documented). And isn't it only for json rpc so should it not be in the table below? And previously in the variable size arrays I'm sure it generated a string, so perhaps that is still the case?
docs/plugin/interfaces/interfaces.md
Outdated
|
||
* JSON-RPC supports the usage of bitmask enums (a combination of enum values can be set in the same enum parameter at the same time). | ||
* This is mapped as an array of values in the JSON-RPC interface. | ||
* See more information about `/* bitmask */` [here](../tags/#bitmask). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No description provided.