On Tue, 10 Apr 2007, Mike Fitzpatrick wrote:
> There is another message type, OFFER, which I left out originally since
> I'd thought it might only be useful as a means to offer some service but
> couldn't really think of a way the sender might request the capability.
> I'll bring it up now in light of some of the recent discussions.
>
> One example being discussed is the idea of a 'display.*' mtype of a
> message, I saw the '*' strictly as a filtering mechanism but others
> think of it in terms of a wildcard expansion to all possible values.
> One place where an OFFER might come into play is with the "I need a
> display task" offer message that can be broadcast using the 'display.*'
This sounds like something which might be better done with the naming service which the "hub" already provides. That is, a display service registers with the naming service (hub), usually at connect time. Later, and app which needs such a service can merely query the hub naming service directly and efficiently. A general broadcast is really only needed in the absence of a naming service.
It would seem that NOTIFY is for publishing events; these are generally broadcast, and any client can subscribe to a class of events (probably by asking to see a pattern of MTYPEs). REQUEST generally goes to a single recipient and is an asychronous request or synchronous RPC. REPLY is an asynchronous response to a REQUEST. One can imagine other options, such as broadcasting a REQUEST, but I think it would be wise to limit the semantics to what is known to be required.
> I had a particular case in mind of calling an IRAF task. So the messages
>
> mtype=set.param args="imfunc.input foo.fits"
> mtype=set.param args="imfunc.output bar.fits"
> mtype=set.param args="imfunc.function sqrt"
> mtype=exec.task args="imfunc"
I suppose one could do this, but wouldn't it be better done as a single REQUEST with arguments? e.g., mtype=iraf.execTask args={{imfunc},{foo},...} Better to avoid assuming state unless you have to. What you have here would probably fail in a concurrent situation.
Probably the MTYPEs want to be more fully qualified, starting with whatever is the highest referenced class is ("iraf" in this example). The semantics of the fields of MTYPE will depend upon the application, but can be used for message addressing (e.g., subscription) by the messaging system.
In a NOTIFY (broadcast event) type of message, probably MTYPE would be something like "<app>.<event-class>.<event>", and a client would say it wants to see (subscribe to) all NOTIFY messages of type "<app>.*".