Generalize ParameterControlServer

[SimonHeybrock]

Need:

• trigger support (zero arguments)
• multi-argument support (e.g., for workpace ID plus rebin parameters)

[MichaelWedel]

It may eventually be easier to use another external library for this:

• pure RPC library http://www.zerorpc.io/
• library with signal/slot mechanism https://pizco.readthedocs.org/en/latest/

But I'd go as far as saying that this is more than maintenance, because for that we need to rethink how multiple objects are exposed on the server side.

For the long term I think this is definitely the more flexible approach.

[SimonHeybrock]

Well, I had RPC in mind. But on the other hand we should not forget that on the backend commands will be distributed via MPI, so it is not clear if it is possible or even makes sense to fit a generic RPC thing on top of it.

[MichaelWedel]

The advantage I can see is that it seems to be completely transparent. In the MPI-case I imagine the MantidBackendWorker on the master rank is exposed through the RPC-interface. The client does not need to care what happens inside the method-call (because it does not know anything about what's going on on the server).

Server:

class Something(object):
   @parameter.setter
   def parameter(self, value):
      if self._is_master():
          # Distribute through MPI - I guess this could be generalized further
          # by putting it into some MPI-attribute-handling class?
      else:
          # Do whatever is appropriate

# Serve "Something"-object through rpc

Client:

something = zerorpc.Client()
something.connect(...)

somthing.parameter = 5

That is, if the properties are accessible like that through RPC. Maybe this is easier to look at together in person.

[MichaelWedel]

Okay, I just tested and the decorator does not seem to work like that with zerorpc.

[MichaelWedel]

With pizco it works, but that requires python3.