|
From: John T. <jd...@ro...> - 2006-11-17 16:07:51
|
Doug Tody wrote: > Hi All - > > In thinking about where this sort of inter-tool messaging might go in > the future, it might be useful to look into the past, for example the > messages which have been defined for the ds9 image display client (which > uses XPA as the underlying messaging transport). See for example > > http://hea-www.harvard.edu/RD/ds9/ref/xpa.html Thanks for this reference - I'm hoping that it won't be beyond us to fashion some kind of plastic-xpa bridge, even at this early stage. I'm sure there's a lot we can and should learn from the way ds9 messaging works. > > One might conclude that messages of this sort can be viewed as a > language, defined separately for each type of tool, based on the types > of data and operations it deals with. I guess we're always going to have a tension between a language tuned to a particular tool and able to expose its full power, and something more general. At the moment we've concentrated on very general messages, although we've toyed with the idea of exposing the full Aladin scripting interface through Plastic. There's probably room for both, though you get a bit tangled up when you have several messages that essentially do the same thing. > When a language becomes rich > enough one would probably prefer to register the namespace or schema > for the language, not the individual elements of the language itself. > Interesting. I wonder whether it's feasible for us to aim at rich languages rather than very simple operations, given the cross-organisation nature of the endeavour. Perhaps I'm being unambitious. However we do this, my feeling at the moment is to keep the messages fairly short strings, rather than (say) going down the route of making them xml. This keeps plastic simple enough to use from the command line in Python. As for namespacing, one of the benefits of using ivoids was that we get namespacing through the authorityIds. At the moment this is purely for the human's benefit - as far as an app is concerned the messages are opaque strings and no plastic app can infer that ivo://votech.org/.../votable/loadFromUrl is related to ivo://votech.org/../votable/showObjects . John > - Doug > > > On Fri, 17 Nov 2006, Roy Williams wrote: > >> John >> >> Following your logic, this means that VOEvents can also be registered >> individually, rather than registering the server that handles them, >> as Ray suggests. I understand that LSST will be putting out thousands >> of event notices every night. Do you think the VO registry system >> will be able to handle the load? >> >> Another problem is inflexibility. Suppose a group wishes to >> experiment with their own dialect of messages, and they want to >> change rapidly, adding and deleting. In the official (Ray) scheme, >> they would have a standalone message registry that may or may not be >> registered with the VO registry. In your scheme, each message is >> added and deleted from the entire global VO registry. >> >> Of course it is much more convenient to have "everything in the >> registry", it is a one-stop shop instead of a two-stage process. But >> perhaps not always the best solution....... >> >> Roy >> >> >> >> John Taylor wrote >>> a search of the registry reveals the ivo://..../loadVOTable message >>> >>> Ray Plante wrote: >>>> Instead, I would recommend the approach that is to be used by the >>>> VOSpace standard in which names are identified using a # suffix; e.g., >>>> >>>> ivo://votech.org/plastic#info/getIVORN >>> >> > -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
