On Sat Feb 28, 2026 at 7:11 AM CET, John Hubbard wrote: > The sync/async naming that GSP RM uses is a little bit "off". I > spent some time discussing it with them, and the problem is that > sync/async is a concept that is somewhat independent of whether > a reply is expected. Usually, sync means a blocking wait for a > response, which is not necessarily required in all case with > GSP RM calls. > > The naming would be better here if it reflected simply that > a response is expected, or not. I don't have great names for > that, but "fire and forget" works well for what we have so > far called "async". So we could do create a convention in which > no annotation means that the API has a response that will come > back, and some abbreviated for of "fire and forget" or "one way" > added to the function name would mean that no response is > expected.
I think the relevant information for the caller is whether the call is blocking or non-blocking; i.e. do we have cases where we want to block, but discard the reply, or expect a reply but don't want to wait for it? So, unless there is additional complexity I'm not aware of, I feel like send_command() and send_command_no_wait() should be sufficient. (Maybe send_command_wait() if we want to be a bit more explicit.) As for the specific commands, we could have traits to control whether blocking or non-blocking submissions are allowed for them in the first place, i.e. this gives us some control about whether a reply is allowed to be discarded through a _no_wait() submission etc.
