Thread: [Plastic-devs] Re: Displaying VOEvents in Aladin through Plastic
Brought to you by:
johndavidtaylor,
thomasboch
Menu
▾
▴
plastic-devs
|
From: Alasdair A. <aa...@as...> - 2006-03-14 17:32:10
|
Just as a heads up for those of to whom this is new, the following comes out of a discussion John Taylor and I had at the VOTech DSRP meeting in Sorrento last week. For those of you on the VOEvent list, information about Plastic can be found at http:// plastic.sourceforge.net/ Thomas Boch wrote: > John Taylor let me know you had some interest in using Aladin to > display > VOEvents through a Plastic message. I am interested in knowing more > about this ... Do you have a well-defined use case ? What kind of > message should Aladin support to let you perform what you have in > mind ? > This could be also discussed on the plastic-devs mailing-list. The use case for pushing VOEvent messages via Plastic is two-fold, at least as far as I've got at the moment... Firstly to inject a "hand-built" message into the VOEvent Network via a Broker or Relay. Secondly for the user's client software (recieveing a message from the network) to "hand" the message onto local display applications. An event message is (almost always) include at the very least an RA and Dec inside the <WhereWhen> element. Additionally it could contain references to retrievable (or embedded) data products such as finding charts, actual data, spectra, light curves, or other tabular data. In Aladin's case, at the basic level, I'd like it to consume a VOEvent message and plot the RA & Dec as a point. Yes, I could just push a ivo://votech.org/sky/pointAtCoords message to Aladin, but I'd like the option for more to be done... Perhaps in future Aladin, or another display app, could parse the message and display all the applicable data products, e.g. retrieve and plot up a data image and the superimpose and error circle and co- ordinates of the event? So I'd like to propose a, ivo://votech.org/voevent/handleEvent Arguments: xml: String Returns: void Where we pass a VOEvent XML message as a (escaped?) String into the Plastic application, which then returns a void. What the application then does with this message is (of course) up to it! Cheers, Al. |
|
From: Alasdair A. <aa...@as...> - 2006-03-14 19:45:43
|
Robert Hanisch wrote: > Alasdair Allan wrote: >> Perhaps in future Aladin, or another display app, could parse the >> message and display all the applicable data products, e.g. retrieve >> and plot up a data image and the superimpose and error circle and co- >> ordinates of the event? > > DataScope already does this, taking VOEvent notices from VOEventNet at > Caltech. Take a look at both tools starting from us-vo.org. And > DataScope > links to Aladin for display and overlay. I think the question at that point is how does DataScope do this? What we/I was proposing was a standard Plastic hook which can be used by any Plastic-enabled app to consume or emit to other apps a VOEvent message. Personally I was thinking about using to push hand crafted solar events from Elizabeth Auden's generator into the event network via a broker. Al. |
|
From: Alasdair A. <aa...@as...> - 2006-04-25 17:25:23
|
I'd like to return to the topic of passing voevent messages to Plastic apps as an entity, rather than first parsing the messages, extracting the co-ordinates, and passing those instead... I'd therefore like to introduce/propose void ivo://votech.org/voevent/handleEvent( String xmlMessage ) 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, or a broker could take the message and pass it into the emerging VOEventNet. Are there any real objections to this? Discussion? Anyone? Al. |
|
From: Mark T. <m.b...@br...> - 2006-04-25 17:32:00
|
On Tue, 25 Apr 2006, Alasdair Allan wrote: > I'd like to return to the topic of passing voevent messages to > Plastic apps as an entity, rather than first parsing the messages, > extracting the co-ordinates, and passing those instead... > > I'd therefore like to introduce/propose > > void ivo://votech.org/voevent/handleEvent( String xmlMessage ) > > 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, or a broker could take the message and pass it into the > emerging VOEventNet. > > Are there any real objections to this? Discussion? Anyone? Sounds fine to me. Obviously a listener that was going to do something with such a message would need to be VOEvent-aware (contain a VOEvent message parser) well as PLASTIC-aware. Do you have particular applications in mind for this? I'm not really up on what's what in VOEvent. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: Alasdair A. <aa...@as...> - 2006-04-25 17:40:16
|
Mark Taylor wrote: > Alasdair Allan wrote: >> I'd therefore like to introduce/propose >> >> void ivo://votech.org/voevent/handleEvent( String xmlMessage ) > > Sounds fine to me. Obviously a listener that was going to do > something with such a message would need to be VOEvent-aware > (contain a VOEvent message parser) well as PLASTIC-aware. Yes... > 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 But for my own use I'm going to make the VOEvent broker (see http:// www.estar.org.uk/wiki/index.php/VOEvent) Plastic aware and allow it to ingest VOEvent messages from publishers/authors via this means and inject them into the VOEventNet backbone network. In other words, a simple way to publish event messages. Al. |
|
From: Mark T. <m.b...@br...> - 2006-04-26 09:37:19
|
On Tue, 25 Apr 2006, 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. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: Alasdair A. <aa...@as...> - 2006-04-26 09:42:10
|
>>> 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. |
|
From: John T. <jon...@gm...> - 2006-04-26 11:00:23
|
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 > |
|
From: Mark T. <m.b...@br...> - 2006-04-26 11:20:36
|
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/ |
|
From: Alasdair A. <aa...@as...> - 2006-04-26 11:34:17
|
Mark Taylor wrote: > 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. I'd probably support this point of view, it seems the most light weight. Keeping the spec as simple as practicable seems like a good goal... Al. |
|
From: John T. <jon...@gm...> - 2006-04-26 12:27:17
|
Absolutely. Funny how the more you look at a problem the bits and pieces you feel the need to add. And thus, SOAP was born. John Alasdair Allan wrote: > > Mark Taylor wrote: >> 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. > > I'd probably support this point of view, it seems the most light > weight. Keeping the spec as simple as practicable seems like a good > goal... > > 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 > |
|
From: Pierre F. <fer...@si...> - 2006-04-27 09:43:56
|
Dear Plastic developers,
I'm playing with the last Plastic developements/implementations and I
must say that I am really positively surprise by the result.
Just one point about the Plastic Hub. I wonder if it is not too
difficult for a user to understand : if and why he has to launch a Hub ?
which one ? if and why he has to register each collaborative
applications ? If and how he can stop the current plastic Hub ?
I) One solution could be :
--------------------------
A) When a Plastic compatible application starts:
1) If it has an inside plastic hub capability, it launchs it, but
only if there is not another Hub already runnning
2) Systematically it registers itself
B) When this application stops:
if it is the last registered application, it tries to stop the hub
if it can.
The B) point means that it could be interesting to have a PLASTIC
message asking to the PLASTIC hub to stop itself.
Or we can imagine that the PLASTIC HUB should stop itself when the last
client unregisters.
We can also imagine that a plastic hub implementation should remove a
registered client if it can not contact it (crash...).
II) Another solution could be:
------------------------------
A) When a Plastic compatible application starts, it does a
pre-registration. I mean, it writes somewhere (.plastic dir)
that it is running and what is its plastic address (?)
B) When a Plastic Hub starts, it will register automatically all
"pre-registered" applications.
C) Whend a Plastic compatible application wants to publish data
1) If there is no running plastic hub, it tries to launch one if it can
2) it publishs its data
For the stop phase, we can follow the same rules that in I) proposition
The second proposition is certainly the better (the hub is running only
if it is required). But it could imply a complex plastic address
negociation between a "pre-registered" application and a new running hub.
Some comments ?
Regards
Pierre
|
|
From: Alasdair A. <aa...@as...> - 2006-04-27 11:31:36
|
Pierre Fernique wrote: > Just one point about the Plastic Hub. I wonder if it is not too > difficult for a user to understand : if and why he has to launch a > Hub ? which one ? if and why he has to register each collaborative > applications ? If and how he can stop the current plastic Hub ? In the past this hasn't been a problem because the hub was the ACR, now that this isn't necessarily the case perhaps we have to think about it a bit... However I think this is a problem for application developers rather than users. > I) One solution could be : > -------------------------- > A) When a Plastic compatible application starts: > 1) If it has an inside plastic hub capability, it launchs it, > but only if there is not another Hub already runnning Or alternatively starts up the generic plastic hub, the hub doesn't have to be internal to be started from an application. You only have to look at TOPCAT to see examples of how this works in practice. > 2) Systematically it registers itself Some applications automatically register themselves (or attempt to), some don't, I think that's a choice for the developer. > B) When this application stops: > if it is the last registered application, it tries to stop the > hub if it can. Again seems like a choice for the developer, but yes, this might be okay, but only if it was the application that started the hub in the first place. After all if it was already running when it started up, then the application should leave things as it found them. > The B) point means that it could be interesting to have a PLASTIC > message asking to the PLASTIC hub to stop itself. Can't we do that already, if not it seems like a reasonable capability (message) to add. Although I think there Plastic hub should be able to say "no", it should be a request, not a demand. > Or we can imagine that the PLASTIC HUB should stop itself when the > last client unregisters. No, no and thrice times no. At least not by default. That's an absolutely hideous idea. Think of the hub as a backend daemon rather than a user level application. Would you stop the crond daemon if there wasn't anything currently in a user's crontab file, nope... > We can also imagine that a plastic hub implementation should remove > a registered client if it can not contact it (crash...). I think it already does this... > II) Another solution could be: > ------------------------------ > A) When a Plastic compatible application starts, it does a pre- > registration. I mean, it writes somewhere (.plastic dir) that it is > running and what is its plastic address (?) Maybe > B) When a Plastic Hub starts, it will register automatically all > "pre-registered" applications. Puts a big burden of effort onto the application developer though? You now have to be able to cope with lighting up a whole bunch of functionality that you'd shut down on start-up because there wasn't a hub, for new applications okay. Reverse engineering this into existing applications might be problematic depending on the architectures involved. > C) Whend a Plastic compatible application wants to publish data > 1) If there is no running plastic hub, it tries to launch one if > it can > 2) it publishs its data To where? If there wasn't a plastic hub running, then there wasn't another plastic aware application running on the same machine (under your scheme) since they would have already started a hub...? > The second proposition is certainly the better (the hub is running > only if it is required). I think you view the hub in a very different way that I do, the hub is a service not something you start and stop with the starting and stopping of a single application. > But it could imply a complex plastic address negociation between a > "pre-registered" application and a new running hub. The word "complex" in the above sentence worries me a lot. We currently have a very light weight messaging system and a fairly flat architecture, lets not pile arbitrary complexity on top. Al. |
|
From: John T. <jon...@gm...> - 2006-04-27 13:51:56
|
Hi Pierre, Good to hear from you. Pierre Fernique wrote: > Dear Plastic developers, > > I'm playing with the last Plastic developements/implementations and I > must say that I am really positively surprise by the result. > > Just one point about the Plastic Hub. I wonder if it is not too > difficult for a user to understand : if and why he has to launch a Hub > ? which one ? if and why he has to register each collaborative > applications ? If and how he can stop the current plastic Hub ? > > I) One solution could be : > -------------------------- > A) When a Plastic compatible application starts: > 1) If it has an inside plastic hub capability, it launchs it, but > only if there is not another Hub already runnning > 2) Systematically it registers itself > B) When this application stops: > if it is the last registered application, it tries to stop the hub > if it can. > > The B) point means that it could be interesting to have a PLASTIC > message asking to the PLASTIC hub to stop itself. > Or we can imagine that the PLASTIC HUB should stop itself when the > last client unregisters. > I think you're right that we need to make things easier to understand for the user, but I believe that how we do it is best left to the individual application developers, rather than prescribed by the plastic spec. I'd certainly agree that no application should "bump" another hub by launching its own internal hub when another one is running. But whether an application registers itself automatically or automatically starts a hub is probably best left in the hands of the individual applications, since they know their users best. As for shutting down hubs, I see no reason why we can't give applications the power to leave the system as they found it. If the application didn't start the hub, it probably is polite not to shut it down. If the application DID start the hub, then yes it could request that it shuts down. So, in my opinion we can agree on a message that requests hub shutdown. How an individual application uses it is up to that application's authors. How an individual hub implements it (ignore it? prompt the user? shut down without question?) is probably a decision for the hub author, in consultation with users. I don't _think_ it needs to mandated as part of the spec. I should point out that any application that can control the system browser (e.g. a java web started application) can start the AR hub automatically by requesting a particular URL. This functionality is built in to the AR's Finder class. I have a Java library that uses this and allows the application developer to construct a policy for how he wants to deal with starting Plastic: e.g. do nothing/wait (blocking) for a hub/start the AR-hub automatically. If anyone's interested it's on the website. > We can also imagine that a plastic hub implementation should remove a > registered client if it can not contact it (crash...). > Again this is an implementation detail. In the AR-hub there already is a facility to manually "purge" dead applications. I didn't make it automatic as I wasn't sure if there could be transient effects that would occasionally cause an application to not respond, but actually to be alive and well. Do people want me to make it automatic (one strike and you're out?)? > II) Another solution could be: > ------------------------------ > A) When a Plastic compatible application starts, it does a > pre-registration. I mean, it writes somewhere (.plastic dir) > that it is running and what is its plastic address (?) > B) When a Plastic Hub starts, it will register automatically all > "pre-registered" applications. > C) Whend a Plastic compatible application wants to publish data > 1) If there is no running plastic hub, it tries to launch one if it > can > 2) it publishs its data > > For the stop phase, we can follow the same rules that in I) proposition > > > The second proposition is certainly the better (the hub is running > only if it is required). But it could imply a complex plastic address > negociation between a "pre-registered" application and a new running hub. > > Some comments ? I think these are interesting ideas and best addressed by the application writers (though there's nothing wrong with us publishing our experiences and "best practice" to help new folk along.) Of the apps I've written, most of them use the library referred to above, and simply wait for a Plastic connection. e.g. http://plastic.sourceforge.net/multiproject/tabstat/tabstat.jnlp will just sit there waiting for you to start Plastic, and then connect automatically. On the other hand this application: http://plastic.sourceforge.net/multiproject/vast/vast.jnlp NEEDs the A(C)R to do anything, and so will automatically start the AR (after humbly prompting the user). John |
|
From: John T. <jon...@gm...> - 2006-04-27 13:56:18
|
> > > II) Another solution could be: > ------------------------------ > A) When a Plastic compatible application starts, it does a > pre-registration. I mean, it writes somewhere (.plastic dir) > that it is running and what is its plastic address (?) I probably haven't thought this bit through enough, but at first glance it could be quite difficult to implement. You'd either need the client to implement a new additional method comeAndRegisterWithMe(PlasticHubListener hubInstance) or define a new message ivo://../hubStarted that all apps would be obliged to understand. Not impossible, but a bit more complicated than what we have now. |
|
From: John T. <jon...@gm...> - 2006-04-26 12:23:48
|
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 > > |
|
From: Thomas B. <bo...@ne...> - 2006-04-28 07:56:25
|
Hi all, > 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. I also agree to try to keep the protocol as simple as possible and to put the complexity on the application side (if needed). Thomas |
|
From: John T. <jon...@gm...> - 2006-05-08 18:01:00
|
Thomas Boch wrote: > Hi all, > > > >> 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. >> A point of order on the "ART" acronym. For the sake of consistent branding I should point out that we've decided to stick with "AR - Astro Runtime" and ACR/ASR to distinguish between the client and server variants. Actually, it's really because we can't be bothered changing the promotional merchandise (T shirts, mugs etc). For the same reason, we decided not to go with "Flexible Astro Run Time". John PS I'm joking about the merchandise. It's an idea though...we could promote our work at the IVOA with free Plastic Mugs, Plastic Pens..... ;-) |
|
From: John T. <jd...@ro...> - 2006-04-26 12:21:50
|
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 >> > |
|
From: Alasdair A. <aa...@as...> - 2006-04-26 12:41:00
|
John Taylor wrote: > 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. Does seem cleaner to me... Al. |
|
From: Alasdair A. <aa...@as...> - 2006-04-25 17:41:24
|
Alasdair Allan wrote: > I'd therefore like to introduce/propose > > void ivo://votech.org/voevent/handleEvent( String xmlMessage ) Possibly it should be, int ivo://votech.org/voevent/handleEvent( String xmlMessage ) returning a 1 on successful parse, and a 0 on a fail? Feeback is always nice... Al. |
|
From: Mark T. <m.b...@br...> - 2006-04-26 09:22:18
|
On Tue, 25 Apr 2006, Alasdair Allan wrote: > > Alasdair Allan wrote: > > I'd therefore like to introduce/propose > > > > void ivo://votech.org/voevent/handleEvent( String xmlMessage ) > > Possibly it should be, > > int ivo://votech.org/voevent/handleEvent( String xmlMessage ) > > returning a 1 on successful parse, and a 0 on a fail? Feeback is > always nice... Good idea, except better to use a boolean return, which is distinct from an integer in XML-RPC. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: Alasdair A. <aa...@as...> - 2006-04-26 09:32:13
|
Mark Taylor wrote: > Alasdair Allan wrote: >> Alasdair Allan wrote: >>> I'd therefore like to introduce/propose >>> >>> void ivo://votech.org/voevent/handleEvent( String xmlMessage ) >> >> Possibly it should be, >> >> int ivo://votech.org/voevent/handleEvent( String xmlMessage ) >> >> returning a 1 on successful parse, and a 0 on a fail? Feeback is >> always nice... > > Good idea, except better to use a boolean return, which is distinct > from an integer in XML-RPC. Fair point... Al. |
