Clean up Gorums method options about gorums HOT 6 CLOSED

Some further thoughts. I've been thinking about the name gorums.qc_future. I think we should rename it to gorums.async, since that has become the de facto naming for such call semantics, even though it isn't exactly the async/await semantics of some languages. Thoughts? @tormoder @leandernikolaus @Raytar

from gorums.

Some further thoughts. I've been thinking about the name gorums.qc_future. I think we should rename it to gorums.async, since that has become the de facto naming for such call semantics, even though it isn't exactly the async/await semantics of some languages. Thoughts? @tormoder @leandernikolaus @Raytar

Is the idea still to make it work like the ordered option, such that you specify gorums.quorumcall and gorums.async? In that case, does it make sense to use it with any other call types? Can a correctable be async?

from gorums.

This is the question. I'm considering whether or not it makes sense to use async as a secondary option to quorumcall. Not sure it makes sense to use it along with the other call types, such as correctable, since correctable variants follow a similar design as that of async. To that end, maybe the correctable variants are really sub types of async. But there are essentially three variants:

• async (currently qc_future)
• correctable
• correctable_stream (currently this only requires correctable along with the rpc method being server streaming.)

from gorums.

(It's been a long time and I don't have the bandwidth to look at the details).

future/async for quorumcall was, as I remember it, just a "programming feature" to make the client able to execute quorum call asynchronously in code. It was really more of a convenience feature, and clients could write the wrapper themselves. I.e. it is not a "property" of the underlying call.

A correctable is inherently async, since a client may get an initial result, but the result may be updated several times asynchronously and concurrently with the client using the initial reply.

from gorums.

Below is one idea for the option combinations that we can support. It feels a bit unnatural to require async together with correctable.

What do you think?
Anyone have better ideas?? @tormoder @leandernikolaus @Raytar

  // New ordered synchronous RPC call (not a quorum call, but one-to-one call)
  rpc OrderedRPC(Request) returns (Response) {
    option (gorums.ordered) = true;
  }

  // Regular synchronous quorum call
  rpc QuorumCall(Request) returns (Response) {
    option (gorums.quorumcall) = true;
  }

  // This is the Qc_Future
  rpc AsyncQuorumCall(Request) returns (Response) {
    option (gorums.quorumcall) = true;
    option (gorums.async) = true;
  }

  // Ordered quorum call (new)
  rpc OrderedQuorumCall(Request) returns (Response) {
    option (gorums.quorumcall) = true;
    option (gorums.ordered) = true;
  }

  // This is the new Qc_Future with ordering (not yet merged)
  rpc OrderedAsyncQuorumCall(Request) returns (Response) {
    option (gorums.quorumcall) = true;
    option (gorums.async) = true;
    option (gorums.ordered) = true;
  }

  rpc Correctable(Request) returns (Response) {
    option (gorums.correctable) = true;
  }

  rpc CorrectableStream(Request) returns (stream Response) {
    option (gorums.correctable) = true;
  }

from gorums.

Closing since this is now implemented in the reorg-generator branch.

from gorums.