Apps Messaging - Semantics of a Message

Doug Tody dtody at nrao.edu
Tue Apr 10 17:38:46 PDT 2007


On Tue, 10 Apr 2007, Mike Fitzpatrick wrote:

>> I think I get the idea, but this is really rather strange.  We would
>> like to display an image (for example), so we broadcast a display
>> request to anyone who might be out there, and they all on their own
>> display the image, or do some other random thing which is similar?
>
> Of course it wouldn't be a random thing, we'd assume the developer
> would read the spec's definition of the 'display' class and do something
> along those lines in the context of his/her app.  But how is sending a
> display request to some anonymous process for handling that much
> different than IRAF using the image display without knowing specifically
> whether it's XImtool or DS9 on the other end.  Just as the only require-
> ment is an understanding of the IIS protocol, in the msg  system the
> only requirement is an understanding of a display.fits message (and
> implicit agreement that it does "the right thing").

The difference is you are sending the request to a specific tool
which is known to be able to handle the specified request ("display"
or whatever).  You also know that you may be able to follow up with a
"read cursor" request or some such, to the *same tool*, since you
know where you displayed the image.  If the sequence of requests
goes to random destinations, it won't work, and probably the poor
user will become very confused when the program hangs, because some
app is waiting for input and they don't know which one.

This is much different than *broadcasting* the request blindly
to anyone who might be out there; in a complex scenario, multiple
recipients might act on the same request and things could become
very confused.

I suspect what really happens in PLASTIC apps is that multiple tools
are found which can service the request, and the user is asked to
pick the one which is most appropriate for what the user wants to do.
Then the request is sent to the selected tool.  More commonly, only
a single tool is started up, and the application only finds one and
automatically sends requests to it (all of which is good).

Isn't what is actually needed here, the ability to dynamically discover
apps/tools which can service a certain request (or class of requests),
and then communicate with them via messaging?

Also: if you are defining classes of data (image, table, etc.),
and operations upon them, then you are defining an object model,
regardless of whether you do it in an adhoc or deliberate fashion,
or some combination of the two (extension).  This is what we do when,
for example, XImtool and DS9 can respond to the same requests.

The only issue here is blindly broadcasting requests (note: if
there is only one instance of a tool which can receive the request,
it is not blind).  There is nothing wrong with defining standard
operations that can be implemented on a class of data, or providing
simple dynamic connection capabilities such as PLASTIC provides.

 	- Doug



More information about the apps mailing list