Re: [Plastic-devs] Passing VOEvents via Plastic

[Mark T. <m.b...@br...>]

On Wed, 26 Apr 2006, John Taylor wrote:

> This throws up a problem that's been bothering me for a while.  If you 
> fire both messages then sure, both VOEvent aware and non VOEvent aware 
> tools can do something with it.  But what about tools that can deal with 
> both messages (it's conceivable that Aladin, for example, will want to 
> include VOEvent stuff).  We need a way of associating the messages so 
> that our hypothetical tool knows that it only need act on the more 
> "sophisticated" message.
> Mark - we discussed this at Sorrento .... can't quite remember what our 
> conclusions were...did we say something like we send an array of 
> messages, in the order that we'd prefer them acted on, and the hub sends 
> the off the first one that matches?

I don't think we reached a conclusion, however my thoughts are as follows:

Since it's now possible to ask the hub which listeners support which
messages, this situation can be handled intelligently by the client - 
a VOEvent dispatching agent will find out which listeners support 
voevent/handleEvent and send handleEvent messages to them; 
if there are any registered listeners which support /sky/pointAtCoords 
and not handleEvent then send a pointAtCoords to them.

In the interests of keeping the protocol/hub specification itself
as simple as possible consistent with the functionality we need,
I'm of the opinion that it's better to leave this to the clients
than to introduce new hub methods to support this behaviour.  Of course 
PLASTIC toolkits such as the AG/ART one and PlasKit should probably
provide canned routines to do this sort of thing so that application
writers don't have to reinvent the wheel every time.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/