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

host_server and target_client libraries #37

Open
t-moe opened this issue Jun 26, 2024 · 3 comments
Open

host_server and target_client libraries #37

t-moe opened this issue Jun 26, 2024 · 3 comments
Labels
open to sponsorship This issue is something James wants, and would be willing to prioritize as sponsored/contract work

Comments

@t-moe
Copy link

t-moe commented Jun 26, 2024

I would be nice to have "host_server" and "target_client" libraries of postcard-rpc. So the MCU would be the one initiating the request to the PC and the PC would answer the rpc calls. Everything else would be the same.

I asked @jamesmunns via Matrix regarding this, here are his responses:

So: postcard doesn't have code for this yet. The protocol has nothing special that forces it to be the orientation it is, that's just how I normally set it up.
I'm very open to having "host_server" and "target_client" libraries: at least the latter I will also want for MCU-to-MCU comms, but I don't have any plan to build it right now.

I also asked about whether there are some big roadblocks in the way, and James responded with:

nah, there's sort of practical limitations maybe, depending on what route you go:

  • honestly the host_client code might be possible to just support with alloc, you might be better off with a different channel (tokio channel is used, could be cfg'd to something else), but it's really not THAT heavy, though I'm not sure how much "slack" you have wrt RAM usage on your current app
  • if you want to make a much lighter client that can only support one "in-flight" request at a time, that'd probably make it much easier to handle no_std, but would be more "novel" work
  • for the PC server, it'd probably be pretty easy to make a dispatcher that takes like HashMap<Endpoint, fn() -> Box<dyn Future<Output = Result<Vec, Something>>>, as a dispatcher

I'm currently a bit on a tight schedule with my current client, so I opted for implementing my own very simple rpc logic on top of postcard for now, as this was just quicker to do. But I'll probably revisit this postcard-rpc as soon as our rpc interface grows larger...

@jamesmunns
Copy link
Owner

Just noting that I am open to PRs here, feel free to @ me if anyone has any questions, or would like to pick up the work.

@jamesmunns
Copy link
Owner

Also noting that by adding a "target client" library, this would unlock MCU-to-MCU comms. I continue to be very interested in adding this, but haven't needed it, so haven't taken time to design it.

I'm very open to PRs or sponsorship if folks are interested in making this happen :)

@jamesmunns
Copy link
Owner

Note that the changes between v0.7 and v0.10 makes it possible to have a host_server (there is a test_channels implementation that runs on the host for testing, using a tokio channel as the "wire").

I don't have a target_client implementation yet, but I am open to implementations of this still.

@jamesmunns jamesmunns added the open to sponsorship This issue is something James wants, and would be willing to prioritize as sponsored/contract work label Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
open to sponsorship This issue is something James wants, and would be willing to prioritize as sponsored/contract work
Projects
None yet
Development

No branches or pull requests

2 participants