-
Notifications
You must be signed in to change notification settings - Fork 24
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
base: dev
Are you sure you want to change the base?
Conversation
This is an initial commit to start development of this feature in its own feature branch
44ada35
to
7f7579a
Compare
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.
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? |
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. |
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