All,
Well there hasn't been a lot of discussion yet, unless my subscription to the IVOA lists is going through yet another phase where I don't seem to get any messages for some obscure reason unknown to modern science, so here goes...
Mark Allen wrote:
> 1. Investigate the scope of an Applications messaging IVOA standard.
>
> 1.1 Open mailing list discussion on messaging between VO apps in
> general.
> - capture major concepts
For those that haven't read it yet, people should go and have a look at the PLASTIC IVOA note,
http://ivoa.net/Documents/latest/PlasticDesktopInterop.html
and while we're not talking specifically about PLASTIC here, but as an existing highly successful standard which has picked up momentum just by being really easy to adopt and use, we really need to start our discussions with a hard look at it.
One thing that PLASTIC doesn't do and I've been using it for is hub to hub transport. However I've more or less solved that (at least for my own purposes) through using gateway applications. How? Well...
I run up a PLASTIC hub on the two machines I'm interested in (usually a backend server with a daemon that is interested in sending PLASTIC messages, and on my own desktop machine where I'd be interested in receiving them).
I then start up a copy of my 'gateway application' on each of these machines. The application registers with their appropriate local PLASTIC hub, however they also bring up (in my hacked together version) a simple raw TCP connection between the two gateway applications (you could imaging a more sophisticated arrangement of XML-RPC server/client between the two gateways).
At this point, whenever the gateway app gets a PLASTIC message from its local hub, it forwards it out along the TCP connection to the other gateway application, which sends it via PLASTIC XML-RPC into the "other" local hub (so it looks to the second hub as if its coming from the gateway application itself).
This works surprisingly well, and adding the concept of a PLASTIC Gateway to the menagerie of existing PLASTIC Hub and Client types might well be a good idea. I've certainly found it useful, and it adds a new capability to the standard. However applying the KISS principle I think its important to keep this functionality out of the Hub standard itself
> - identify interested parties (Feb 2007)
Me! Me!
> 1.2 Prepare a short note on "Applications messaging for VO tools"
> - define the scope of an Applications Messaging IVOA standard
> - outline the major issues involved, and put the current possibilities
> into the context of short and longer term goals. (end-Feb 2007)
I'll state up front that I think the standard has to be language neutral. We can't restrict ourselves to a single language, or optimise the standard so it works best with a single language. So a standard that relies on Java RMI alone is right out.
We also want whatever we settle on to be blinding simple and widely implemented. For instance almost all languages have an XML-RPC implementation, even Javascript, and XML-RPC is a lot easier for people to get their heads around than (for instance) SOAP. We're writing the specification for a simple message passing system here, not a overly complex full featured web service. We have to keep things simple.
PLASTIC is one of the few "new" things that has come out of the IVOA that I've seen people using in the wild, actual astronomers independently discovering and using it because "Wow, that solves my problems!" rather than after careful education.
Like VOEvent, PLASTIC has been a quick win for the VO community and serves as a perfect taster for what the VO can do for people, a hook if you will. Astronomers see in the interesting and new stuff they can now accomplish and think "Hmm, does this VO thingy do anything else useful?"
We're facing a major uphill battle for mind-share right now, we need some quick wins.
Cheers,
Al.
Received on 2007-02-06Z13:24:24