plastic-devs Mailing List for PLASTIC (Page 10)
Brought to you by:
johndavidtaylor,
thomasboch
Menu
▾
▴
plastic-devs — Plastic Developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(15) |
Nov
(11) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1) |
Feb
(110) |
Mar
(36) |
Apr
(55) |
May
(42) |
Jun
|
Jul
(42) |
Aug
(14) |
Sep
(34) |
Oct
(7) |
Nov
(35) |
Dec
(5) |
| 2007 |
Jan
(3) |
Feb
(5) |
Mar
(18) |
Apr
(10) |
May
(10) |
Jun
(9) |
Jul
(27) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mark T. <m.b...@br...> - 2006-05-03 11:00:56
|
On Wed, 3 May 2006, Mark Taylor wrote: > Hi Marco, > > On Wed, 3 May 2006, Marco Comparato wrote: > > > Hi Mark, > > > > I got some problems with Topcat too:( > > sorry about that. > > > I don't receive showObjects messages from your application. It should > > send this messages when sending subsets, am I wrong? It works fine with > > the loadFromURL message (I mean when it loads a votable). > > Yes, you're right, there seems to be a problem with sending this > message to XML-RPC clients (java RMI ones are OK). I will try to > track it down. My fault - I was sending a List of Longs not Integers, which is illegal over XML-RPC (though it works with java). I've built a fixed version, which you can find at ftp://andromeda.star.bris.ac.uk/pub/star/topcat/pre/topcat-full.jar sorry about that. I'll try to issue a public release with this fix in before Victoria. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: Mark T. <m.b...@br...> - 2006-05-03 10:06:28
|
Hi Marco, On Wed, 3 May 2006, Marco Comparato wrote: > Hi Mark, > > I got some problems with Topcat too:( sorry about that. > I don't receive showObjects messages from your application. It should > send this messages when sending subsets, am I wrong? It works fine with > the loadFromURL message (I mean when it loads a votable). Yes, you're right, there seems to be a problem with sending this message to XML-RPC clients (java RMI ones are OK). I will try to track it down. > Directory names are another issue, if a directory name is longer than 8 > chars it is renamed to fit the 8.3 file name format. Do I have to handle > that from my side? I get long names from other application (Aladin and > XMDV). Yuk. I haven't tested on Windows so I've never seen that before. I'll try to work out what/why/when, but can't do it straight away since I don't have a Windows machine to hand. In the mean time if this sounds like familiar behaviour to any Windows/Java people out there advice would be gratefully received. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: Marco C. <mc...@oa...> - 2006-05-03 09:55:13
|
Hi John, I get another url format from xmdv file:/c:/......... :( Marco:) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Marco C. <mc...@oa...> - 2006-05-03 09:48:56
|
Mark Taylor wrote: > This is to announce the release of TOPCAT v2.1. > > Headline enhancements since the last advertised release (v2.0) are: > > - Extensive support for the PLASTIC tool interoperability protocol > - New stacked line plot window > > plus a bunch of other stuff, described in detail at > http://www.starlink.ac.uk/topcat/sun253/versions.html > > Find it as usual at > > http://www.starlink.ac.uk/topcat/ Hi Mark, I got some problems with Topcat too:( I don't receive showObjects messages from your application. It should send this messages when sending subsets, am I wrong? It works fine with the loadFromURL message (I mean when it loads a votable). Directory names are another issue, if a directory name is longer than 8 chars it is renamed to fit the 8.3 file name format. Do I have to handle that from my side? I get long names from other application (Aladin and XMDV). I'll try to monitor the messages arriving to the hub to check were the file name conversion is done. Thanks, Marco Ops, I am really sorry, I sent this email almost to everyone on the net:( -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Marco C. <mc...@oa...> - 2006-05-03 09:19:44
|
Thomas Boch wrote: > Hi again, > > I made another update which fixes some problems with the showObjects > message. It should now work properly. > Mark : thanks to Pierre Fernique, the parsing problem has also been > fixed. > Let me know if there are other fixes that should be done before next > week. Hi Thomas, I got some problems trying using Aladin. It seems that Aladin is looking for acr and it doesn't register with hub if acr is not present (it tries to download acr). If I load a votable in aladin I got a wrong url format (file:c:/......, should it not be file:///c:/.....?) Am I doing something wrong or you can confirm this behaviour? Thanks, Marco -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Mark T. <m.b...@br...> - 2006-05-02 08:21:20
|
On Tue, 2 May 2006, John Taylor wrote: > The bug with the HubStopping message not being sent has been fixed in > the next version of the AR Hub. Since no-one dissented I've changed > things so that if you now register with an empty list of supported > messages then you get what you asked for - ie nothing. In other words, > an empty list no-longer means "send me everything", which not only makes > more sense it's rather easier on the brain to code. John, since this is changed behaviour I hope it is accompanied by a change of version number (0.5?). Since the modified build isn't out yet I can't tell whether you've done this. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: John T. <jd...@ro...> - 2006-05-01 23:21:27
|
The bug with the HubStopping message not being sent has been fixed in the next version of the AR Hub. Since no-one dissented I've changed things so that if you now register with an empty list of supported messages then you get what you asked for - ie nothing. In other words, an empty list no-longer means "send me everything", which not only makes more sense it's rather easier on the brain to code. John PS Sending this now even though Noel hasn't released a new build as I'm off to Canada tomorrow. See you there if you're going. |
|
From: John T. <jd...@ro...> - 2006-04-28 10:14:32
|
http://sourceforge.net/project/stats/?group_id=151244&ugn=plastic&type=&mode=60day We seem to be getting several hundred hits a day now - and they're not all me. John |
|
From: Mark T. <m.b...@br...> - 2006-04-28 08:17:25
|
On Thu, 27 Apr 2006, Noel Winstanley wrote: > Hi. > I've fixed this for the latest standalone AR versions (2.2-beta-2) by > including the > BrowserLauncher2 library ( http://sourceforge.net/projects/ > browserlaunch2/ ) - which seems to do a pretty good job, with no > native code. Yup, now works even for me. -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
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: Noel W. <Noe...@ma...> - 2006-04-27 21:56:50
|
Hi. I've fixed this for the latest standalone AR versions (2.2-beta-2) by including the BrowserLauncher2 library ( http://sourceforge.net/projects/ browserlaunch2/ ) - which seems to do a pretty good job, with no native code. I like your simple swing solution, but you're right - this will stumble when it finds a .jnlp file. cheers noel. On 24 Apr 2006, at 19:40, Mark Taylor wrote: > On Mon, 24 Apr 2006, Noel Winstanley wrote: > >>> - Most things I try to do from the GUI just pop a message in a >>> JTextPane: "Cannot control browser Please go to ...". No doubt >>> this is a consequence of the Luddite way I [refuse to] set up >>> my desktop, so you may choose not to regard this as a bug. >>> >> >> most of the things you are doing must be launching links to webpages. >> Java webstart provides extra apis to do this - if the AR isn't >> running under webstart, it falls back to just telling the user where >> to go (so to speak). >> It's a pity that standard java doesn't provide a browser-control >> class - there's a range of 3rd-party libraries (either java code that >> does os-detection, or native code like JDIC) that try to achieve >> this, but few are very good (last time I looked). Maybe I should >> provide something a little more ambitious for the fallback position - >> I'll take a look at what's available. > > Having a horror of relying on anything outside the J2SE I implemented > a pure Swing noddy HTML browser for use in bits of TOPCAT - most of > the > hard work is done by JEditorPane so it's not very difficult. > See > > http://cvsweb.starlink.ac.uk/cvsweb.cgi/java/source/topcat/src/ > main/uk/ac/starlink/topcat/HtmlWindow.java > > if you're interested. Probably wouldn't get far with a .jnlp link > though. > > -- > Mark Taylor Astronomical Programmer Physics, Bristol > University, UK > m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/ > ~mbt/ > |
|
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-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: 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: 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-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: 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: 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: 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 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: 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: 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: 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: 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: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. |
29 messages has been excluded from this view by a project administrator.
