Skip to content

docs: "how to think in postcard-rpc" #102

Description

@jamesmunns

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Q2 '25 TriageItems tracked as part of https://github.com/jamesmunns/postcard/issues/241

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions