Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Plumb RPC listener up to caller #5038
Plumb RPC listener up to caller #5038
Changes from 2 commits
6afa9b4
2a41755
63409c5
52619cb
edb42bb
1a13c3c
370990a
c360b6d
77cbb97
37472e1
1f81d96
c518301
e71565b
70c6ff1
7491090
ff4bf3d
50197cb
a8efb66
5e690bf
f19f5de
37ee0ab
20fc75a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
It doesn't makes sense to add listen_addresses to
RpcHandlers
this just an in-memory way to perform rpc calls, please remove it RpcHandlers.Why did you add it (maybe I'm missing something)?
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.
Just because the RpcHandlers type is what is getting returned to the caller. Would a new return type that can provide both the
Server
and theRpcHandlers
be preferred?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.
Aight, I see one may want to know the listen addrs on the rpc endpoint after calling
spawn_tasks
.It's probably fine to keep the
RpcHandlers
or rename to the RpcService or something, but it needs to documented that is represent a running RPC server as well with the legacyin-memory rpc calls
.We may want to remove latter at some point, it was for WASM stuff before smoldot was a thing...
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.
I added some notes with a link to this comment thread.
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.
I'm fine with this.
But the return type is bit complicated and I don't remember why it's
Box<dyn Any>
but would be much nicer with a wrapper type that has an API to get the listen_addr instead returning a tuple.... because the Server type already has this information.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.
I just used the Server type here, and moved the Drop wrapper up to the point where it was actually needed. Let me know if that suffices.