Skip to content
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

Merged
merged 6 commits into from
Aug 26, 2024

Conversation

nxtum
Copy link
Contributor

@nxtum nxtum commented Aug 16, 2024

No description provided.

Copy link

github-actions bot commented Aug 16, 2024

PR Preview Action v1.1.1-25-g59e77e4
🛬 Preview removed because the pull request was closed.
2024-08-26 08:40 UTC

* 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.
Copy link
Contributor

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


* 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

* 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.
Copy link
Contributor

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
Copy link
Contributor

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

@@ -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|
Copy link
Contributor

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?


* 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).
Copy link
Contributor

@MFransen69 MFransen69 Aug 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we refer to @encode:bitmask (and document thaT @bitmask is deprecated, guess we need to ask sebastian)

@MFransen69 MFransen69 merged commit 4842c25 into rdkcentral:master Aug 26, 2024
8 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants