On 3/1/26 7:03 PM, Alexandre Courbot wrote:
On Mon Mar 2, 2026 at 11:22 AM JST, Eliot Courtney wrote:
On Sat Feb 28, 2026 at 3:11 PM JST, John Hubbard wrote:
On 2/26/26 7:50 AM, Eliot Courtney wrote:
Add sync and async command queue API and the type infrastructure to know
what reply is expected from each `CommandToGsp`.
...
For lack of a better idea i suggest send_and_wait_for_reply +
send_no_reply for now.
One important detail IMHO is that the API cannot be misused, i.e. you
cannot call the fire-and-forget send method on a command that expects a
reply. So the risk is mostly when adding support for a new command - but
if that step is done properly, users will be directed to the right
method by the compiler.
Naming is not *just* about risk of someone misusing it. It's about
being able to read things on the screen and having a good chance of
understanding it.
This, I think, allows us to tolerate more ambiguity in the method names,
as long as their documentation makes up for it. We all agree that
Really, no. Let's do our best on naming, *in addition* to the documentation
and having Rust help lock things down.
`async` and `sync` are not a good fit, but `send`/`send_noreply` should
be tolerable (I'd like to keep the names short if possible)
Or maybe we can use a variant of the trick mentioned by Gary in [1] and
have a single `send_command` method?
[1] https://lore.kernel.org/all/[email protected]/
thanks,
--
John Hubbard
