Re: [Plastic-devs] Passing VOEvents via Plastic

[John T. <jon...@gm...>]

Apologies for having just sent a mail to the same effect....didn't 
refresh my inbox on reconnecting before sending.

Mark Taylor wrote:
> 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
>
>