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. Received on 2007-04-11Z02:59:55