Apps Messaging - Semantics of a Message

[Doug Tody]

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>.*".

 	- Doug