Apps Messaging - Semantics of a Message

[Doug Tody]

Hi Mike -

I'm not sure I understand what the concept is here.  I was thinking
more in terms of a type of service, e.g., an image or table viewer
service/tool, registering with the "hub", after which clients could
expect it to perform some standard operations defined for that type
of client, or at least deal with certain classes of data.  Hence Aladin
would register as an image tool, Topcat and VOPlot as table tools, 
VOSpec, SPLAT, Specview, etc. as spectral analysis tools, and so forth.
A client could query the "hub" to find out what tools are available
to handle a certain type of data.  This would not be enough to describe
the full capabilities of each service, but there are various ways 
that could be handled as well.

You seem to be suggesting instead that an application registers that
it can perform certain types of operations on certain types of data,
indicated via the mtype.  That could also work; I guess in this case
one would be registering the individual capabilities, expressed as
the operations (indicated as mtypes) which the tool supports.  This
almost starts to sound like a MIME-type application registration
scheme rather than a messaging system.

I think the concept of MTYPE, or at least how it would be used,
is still a bit muddy.  In the case here we seem to be focused more
on how to describe services.  Are we trying to define a standard
service model for each major class of astronomical data?  That is, a
set of operations (display, select, etc.), on a certain type of data
(table, image, spectrum, etc.), which a given tool/app can provide
(PLASTIC does seem to be rather like that).  This could be more of
an object request broker problem then a messaging problem.  I agree
that it is another important aspect to this problem.

 	- Doug


On Tue, 10 Apr 2007, Mike Fitzpatrick wrote:

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