Re: [Plastic-devs] Passing VOEvents via Plastic

[John T. <jd...@ro...>]

Actually, this problem goes away for point-2-point messages since client 
A knows what client B will accept and can choose accordingly.  So 
perhaps it's another one of those things not to worry about....if you're 
broadcasting to the whole world you just shouldn't send two messages 
that mean the same thing.  BTW - does anyone use the requestToSubset 
method to send to more than one application at a time?  I wonder whether 
things wouldn't be clearer if we had

request(sender, destination, message, args[]) //goes to a single destination

and

broadcast(sender, message, args[]) //goes to everyone who claims to 
receive it

instead of what we have currently.

Note that I'm not advocating a change right now....just flagging the 
idea up for when we do change (and adopt all those ideas about deferred 
return values etc....)


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?
>
> John
>
> Alasdair Allan wrote:
>>>>> Do you have particular applications in mind for this?  I'm not
>>>>> really up on what's what in VOEvent.
>>>>
>>>> Well obviously I'm someone will implement a VOEvent aware display
>>>> tool (before I have to sit down and do it), e.g.
>>>>
>>>>>> ...so that a Plastic aware display tool could for instance parse
>>>>>> the  message and plot the data products, e.g. a finding chart with
>>>>>> the event RA&Dec marked along with an appropriate error circle
>>>>>> taken from the message
>>>
>>> That's a reasonable thing for a VOEvent-specific tool to do, but
>>> if what you want to achieve by sending a handleEvent message is to
>>> mark a region on the sky, this might be better done by a sky-display
>>> tool such as Aladin, or a catalogue-display tool like TOPCAT, or
>>> some other generic application.  You'll have a better chance of
>>> interoperating with these tools if you send some non-VOEvent-specific
>>> message along the lines of ivo://votech.org/sky/pointAtCoords.
>>> So you might want to consider firing a pointAtCoords event at the
>>> same time as firing a handleEvent.
>>
>> That's certainly how I'm going to start off with things.
>>
>> Al.
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, 
>> security?
>> Get stuff done quickly with pre-integrated technology to make your 
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Plastic-devs mailing list
>> Pla...@li...
>> https://lists.sourceforge.net/lists/listinfo/plastic-devs
>>
>