No subject

[Alasdair Allan]

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.