host_server and target_client libraries

[t-moe]

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]

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]

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]

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.

[zheylmun]

@jamesmunns, I'm also interested in having an MCU act as a "target client".
It's a personal project so I have no way to sponsor anything, but I'd love to contribute.
I have a project with multiple identical M0 components coordinated by a larger BLE MCU over SPI.
I am developing the smaller device first, and would like to transition from using postcard-rpc as the interface for the development of the smaller part into the internal communication protocol of the assembled system.
I believe embedded-io transport (#83) will allow me to develop the initial functionality, as well as put some mileage on the embedded-io PR.
Once I have some more significant hands-on experience with the existing code here I might take a stab at a target client implementation, but I'll open an issue to discuss any insights from you before diving in.

[jamesmunns]

@zheylmun sounds great! Let me know if you have any questions, or feel free to ping me in the matrix chat!