QSpec objects versus passing quorum functions as arguments

[johningve]

I am opening this issue to gather some thoughts on whether quorum specification (qspec) objects have any benefits compared to simply passing the quorum function as an argument to each quorum call.

Currently, a quorum function must be implemented by a qspec object. Qspec objects are stored in configurations:

type qspec struct {}

func (qspec) WriteQF(in *proto.WriteRequest, replies map[uint32]*proto.WriteResponse) (*proto.WriteResponse, bool) {
    ...
}

// Currenlty, the quorum function is made available to quorum call through the qspec object
cfg, _ := mgr.NewConfiguration(qspec{}, ...)
cfg.Write(...)

Alternatively, we could pass the quorum functions to the quorum calls as arguments:

// We could instead pass it to the quorum call directly
cfg.Write(..., func(in *proto.WriteRequest, replies map[uint32]*proto.WriteResponse) (*proto.WriteResponse, bool) {
    ...
})

// This also works without closures,
// and the state of the qspec object can be modified
// if a pointer receiver is used for the QF.
cfg.Write(..., qspec{}.WriteQF)

My thoughts:

• I think that I prefer the "ergonomics" of using a qspec object because implementing the qspec is analogous to implementing the server-side handlers.
• Passing quorum functions as arguments makes it easy to give different quorum functions for subsequent quorum calls.
  • Though I am not sure when this could be useful.

[meling]

As I mentioned in the last meeting, I think we did have the function argument approach in an early version of Gorums. Maybe @leandernikolaus and @tormoder can help me confirm this; I looked at the code, but couldn't find any residue of this code.

I do think that our rational back then was that the qspec would then be decoupled from the caller's code; that is, the developer could think about making quorum calls and getting a single reply back and wouldn't have to see the actual quorum function as part of the execution path.

I think we also discussed back then whether or not to support both alternatives, and opted to pick just one approach for simplicity.

Any thoughts: @hanish520 @r0qs and others...

[meling]

I guess the question is whether or not a qspec belongs together with the configuration object. You could argue that the function argument approach can still be decoupled from the quorum call execution path by defining it outside the code path and just pass it as an argument; e.g., we could have a library of standard quorum functions that you pass in. But in this case, you cannot leverage the locally defined variables inside the quorum function.

[leandernikolaus]

I always thought of a quorum function and qspec as belonging to the configuration, rather than to a specific call. Thus, I find it reasonable, if you want to use different qspecs, to rather use different configurations than passing different

I am unsure whether this is actually possible in the current gorums.

The disadvantage with qspecs, is that someone may actually modify state in these objects, which could be problematic and not thread safe.

[meling]

I'm closing this since there is no clear use case for the function closure approach. Should a use case arise, we can revisit the topic.