Apps Messaging - Semantics of a Message

[Alasdair Allan]

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?

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

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

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

Al.