Apps Messaging - Semantics of a Message

[Mike Fitzpatrick]

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

	But again it's in the interpretation of 'display.*' as to what 
happens, unless we require that apps must register only with complete 
mtypes (in which case we can ignore the wildcard issue altogether).  I'd
rather stay away from explicitly stating types since I can think of a
number of examples where I might want to subscribe to the display.* 
messages but not necessarily act on all of them.  Registering with a
e.g. display.url capability at least implies I will do something with
that message, but (like a lot of people on this thread) what if I'd 
rather just lurk until something interesting comes along? 

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

	This is similar to John's earlier suggestion and something I could
live with.  I would prefer though that we not resort to a iraf.* class
unless we really need to, i.e. if we agree that the argument string to
an exec.task message is assumed to be meaningful to the recipient it 
doesn't matter what form the command takes or that it's IRAF, IDL, or
anything else with an interpreter (Aladin and Mirage have scripting, could
they use this?).  We might need other similar messages to do things like
load a config file or plug-in, launch a command or a new instance of the
app, etc.

	I was aiming for an mtype scheme where messages had some kind of
predictable meaning, but maybe one that varied by context.  For example,
set.param to set a task parameter in the CL is perfectly logical, but a
set.param message to the Hub to set a timeout for synchronous msgs isnt'
quite the same kind of param in the same kind of environment, but is just
as logical given the context.  Similarly, responding to a display.*
message means I'll give it my best effort to do something logical.  The
Apps WG then should find agreement on a (small) vocabulary so there is
predictable functionality to a message, maybe it's the best you can do
with the apps available until you install a different app that handles it
better, but it lets the developers decide what is the best way to
implement a given mtype based on their app.


-Mike