Apps Messaging - Semantics of a Message

[Doug Tody]

On Wed, 11 Apr 2007, Alasdair Allan wrote:

> Doug Tody wrote:
>> 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).
>
> Why? Why not send the display to all the tools running that have registered 
> an interest in receiving a display type message?

I'm sure there are cases where one would like to do that (operate
upon the same data in multiple tools), but the main reason is for
the client app to be able to manage a sequence of requests.  If this
is not an issue, you probably have a very simple client of some sort.

>> 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.
>
> Why wouldn't the user just switch to that tool and manipulate the tool 
> locally, why would they then attempt to muck around managing the tool 
> remotely when they could just use the tool? If you want to return a cursor 
> position from the new tool to the original application, surely the user 
> should trigger a send.position message back into the Hub (which if the 
> original application was interested in such things it could then read).

Displaying an image, and then for example reading the image cursor to
do stellar photometry in the client application, is an example of a very
common use-case (there are an infinite number of such cases).  In such 
a case the client application and the visualization tool act together,
with the tool being driven by the client application.

I don't think it is good enough to require the user to explicitly send
a send.position to some client; in this case we are trying to drive the
tools from the client.  It is sort of like having the client app as a
plug-in to the tool, extending its functionality.

>> 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.
>
> Huh? Sorry Doug, I think you're missing the point here.

See the above use case.  Which tool receives the image cursor read
request?  What if all of them receive it?

>> 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.
>
> Sometimes yes, sometimes no. If you were in my VOEvent over PLASTIC demo in 
> Victoria you'll have seen me send a PointAtCoords messages from the VOEvent 
> client to two display applications simultaneously, both of which did 
> different things with the data for different reasons.
>
>> 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).
>
> Sometimes this is the case, but not always. I don't normally use PLASTIC in 
> this manner.

I am sure that it will work for anyone who develops and demos their own
application.


Anyway - These are good discussions.  We have a new mode of operation
where a number of loosely coupled, independently developed applications
or tools interoperate, which I think is very powerful.  This alone is
not enough however; we will also need actual distributed applications,
which are programmatically controlled in some fashion.

 	- Doug