Assorted notes that I should make more clear for people architecting interfaces with p-rpc. This is "default advice for how james would do it", even if it's not strictly mandatory according to how p-rpc works.
Almost all of these suggestions are "to taste", you can always decide to do something different if it makes more sense for you.
favor more topics/endpoints instead of trying to "multiplex" with enums in them
Any change to data types, including adding/removing fields, or adding/removing enum variants is a "breaking change". If you are prioritizing interface stability/compatibility, consider splitting them up so users with a "compatible subset" of features can still interop.
For example, instead of having a Topic with:
enum Events {
SerialEvent {
// ...
},
RTTEvent {
// ...
},
BLEEvent {
// ...
},
}
// ...
| TopicTy | MessageTy | Path | Cfg |
| ------- | --------- | ---- | --- |
| MonitorTopic | Events | "events" | |
// ...
Consider making:
struct SerialEvent {
// ...
}
struct RTTEvent {
// ...
}
struct BLEEvent {
// ...
}
// ...
| TopicTy | MessageTy | Path | Cfg |
| ------- | --------- | ---- | --- |
| SerialEvent | SerialEvent | "events/serial" | |
| RTTEvent | RTTEvent | "events/rtt" | |
| BLEEvent | BLEEvent | "events/ble" | |
// ...
On the target side: sending to many channels is effectively "free". On the host side, subscriptions are roughly the cost of a tokio channel, it is reasonably cheap enough to select on many channels (up to some reasonable limit, maybe dozens as a guess? worth benching above there) instead of just recv'ing from one. It's also better to just have different parts of your system be independent tasks.
TODO: Review https://github.com/probe-rs/probe-rs/blob/3ddfd10870619fd104e7ed5999e2c5222749405d/probe-rs-tools/src/bin/probe-rs/rpc/client.rs#L504 and see if I have specific suggestions.
Assorted notes that I should make more clear for people architecting interfaces with p-rpc. This is "default advice for how james would do it", even if it's not strictly mandatory according to how p-rpc works.
Almost all of these suggestions are "to taste", you can always decide to do something different if it makes more sense for you.
favor more topics/endpoints instead of trying to "multiplex" with enums in them
Any change to data types, including adding/removing fields, or adding/removing enum variants is a "breaking change". If you are prioritizing interface stability/compatibility, consider splitting them up so users with a "compatible subset" of features can still interop.
For example, instead of having a
Topicwith:Consider making:
On the target side: sending to many channels is effectively "free". On the host side, subscriptions are roughly the cost of a tokio channel, it is reasonably cheap enough to select on many channels (up to some reasonable limit, maybe dozens as a guess? worth benching above there) instead of just recv'ing from one. It's also better to just have different parts of your system be independent tasks.
TODO: Review https://github.com/probe-rs/probe-rs/blob/3ddfd10870619fd104e7ed5999e2c5222749405d/probe-rs-tools/src/bin/probe-rs/rpc/client.rs#L504 and see if I have specific suggestions.