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

JSON RPC2 implementation #129

Draft
wants to merge 5 commits into
base: dev
Choose a base branch
from
Draft

JSON RPC2 implementation #129

wants to merge 5 commits into from

Conversation

DerAndereAndi
Copy link
Member

@DerAndereAndi DerAndereAndi commented Oct 28, 2024

This is an initial commit to start development of this feature in its own feature branch.

Please provide PRs against this branch when adding functionalities. The tasks are being coordinated in #130

@DerAndereAndi DerAndereAndi marked this pull request as draft October 28, 2024 16:43
This is an initial commit to start development of this feature in its own feature branch
@DerAndereAndi DerAndereAndi added the enhancement New feature or request label Oct 28, 2024
sthelen-enqs and others added 4 commits October 29, 2024 15:40
By default go serializes `error` types as an empty struct `{}`, this
patch would adjust that so that errors are serialized as their string
representation by calling `Error()` on any non-nil types that implement
the error interface.

This should be an improvement over the current state as it now allows
identifying the cause of an error from the RPC client. An alternative
could be to serialize the error as a struct of `{"type": <>, "message":
<>}` using reflection to get the type name (and package path) of the
error though I'm not sure if it's necessary and I'd have to check how
easy that would be to get working.
@DerAndereAndi
Copy link
Member Author

If there are no more imminent changes planned, I would like to merge this into the dev branch. We should think of moving the JSON RPC2 interface into its own repo and work on an API design for that as well. What do you think?

@sthelen-enqs
Copy link
Contributor

The only imminent change I had planned would have been dropping the custom serialization of DeviceRemote/EntityRemote, but if I wanted to do that cleanly I'd also have to take a stab at the proposed case normalization in input/output data types. It might make more sense to work on that after this has been split into its own repo as part of the API design.

I'm fine with merging this and preparing to split this into its own repo and then moving from there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants