Apps Messaging - Twin track?

[Alasdair Allan]

Mike,

Sorry its taken me so long to respond to this one, I've been off  
network for a few days.

Mike Fitzpatrick wrote:
> 1)  I have some legacy Fortran code that does the world's greatest  
> N-body
>    simulation of globular cluster evolution.  I would like to plot the
>    evolution at each iteration using VOPlot.
>
>    Missing Concept:  Language support for legacy environments not  
> directly
>        supporting XML-RPC or RMI.

Agreed, this is something we have to look at, and has been batted  
back and forth on the plastic-devs list several times, as has  
removing RMI as a protocol. In fact there is actually unofficial  
support for a REST based transport in the current hub.

Of course its going to be difficult, near impossible, to support any  
legacy environment that doesn't have the concept of sockets. I don't  
think we really want to deal with the added complications of  
environments that don't support sockets, we have to draw the line  
somewhere.

So, basically the most primitive level I'd like to see supported  
would be some sort of serialisation over vanilla TCP. Possibly JSON  
might be a good choice, it has a surprising amount of support in  
legacy languages, and (quite frankly) is so easy to build/parse that  
you you can probably roll your own JSON support in a few hours anyway.

> 2)  I have code that computes a deblended spectral profile of an  
> eclipsing
>    binary.  I would like to plot the spectrum, zoom in on a particular
>    line and overplot my best fit to that feature by sending the  
> data from
>    my fit (without writing an intermediate file).
>
>    Missing Concept:  A data payload with the message instead of a  
> simple
>        file reference.

Actually, I don't think this is a good idea. Having the ability to  
push data inline vastly complicates the protocol because it necessary  
to support arbitrarily large messages. While I can see why you might  
want to do this in the general case, in the specific case of the  
simple messaging protocol we've been tasked to build I think it isn't  
necessary, perhaps even detrimental, to the final goal.

> 3)  I have an instrument simulator (I *really* do) that creates an
>    observation sequence by triggering an action in a "head" process  
> that
>    then cascades to multiple processes controlling different areas  
> of a
>    detector.  As each process completes it should send a 'done'  
> message
>    back to the head node, when all replies are received the trigger  
> process
>    is given a 'done' to complete the observation.  Procs in the  
> chain all
>    know only a 'start' and 'done' message but messages are  
> broadcast based
>    on the type of work they do.  (Note the same example could apply  
> in a
>    pipeline or distributed workflow).
>
>    Missing Concept:  The idea of "message groups", i.e. apps can  
> identify
>        themselves as belonging to a special-interest 'group' rather  
> than
>        simply as having some functionality or handling some data type.
>        Messages can be broadcast only to this group,  apps can  
> enroll in
>        any group but ignore specific messages they cannot handle (e.g.
>        subscribe to the 'plot' group but reject a request to plot a
>        spectrum on a wavelength scale).

Interesting concept, but in general how does this significantly  
improve the protocol. Concentrating on the simple, how does this  
capability improve a users/developers life? I'm not really sure how  
the above generalises to something that people will need enough to  
justify adding additional complications to the protocol.

I'd suggest internal application/group specific messages, basically  
the current PLASTIC spec would support/recommend you using private  
messages rather than adding new message types to the public list, if  
you wanted to do this...

> 4)  a) I want to display a 2-D image to any application capable of  
> rendering
>       it on the screen for me.

PLASTIC can of course do this...

>    b) I want to do the same but only if the app can accept a URL  
> insstead
>       of a local file name,

...and that.

>    c) I want to display an image to a specific frame/plane of the
>       app so I can load it for an animation/blinking.

I think using message fragments we can do this as well...

>    d) I want to display an image to a specific region of the image  
> display
>       window (e.g. as part of a detector mosaic)

...and possibly this, but I think we're starting to move away from  
'simple'.

>    Missing Concept:  Ability to query and/or exploit specific  
> capabilities
>        of an application.

The message fragment capabilities being discussed for PLASTIC v1.0  
should add these capabilities.

> 5)  I want to sent all connected apps a message to "cd" to a specific
>    directory so that subsequent file references will have them see the
>    same files my app sees.
>
>    Missing Concept:  "Context Messages" to create a unified view of  
> the
>        desktop between all applications.

This is a platform specific concept, and is highly contextual, adding  
potentially huge amounts of arbitrary complexity. I'd resist any push  
to add this to the messaging application specification. I don't view  
this as beneficial, in fact quite the opposite, I think this  
capability is potentially a huge security hole. I don't like the idea  
of breaching the sandbox in which the application messaging system  
would operate in quite so flagrant a manner. Basically I don't see  
that this would bring any benefits that outweigh the added complexity  
and security implications, especially since it doesn't actually bring  
any new capabilities to the table.

> 6)  I want to invoke a task on an app with a command shell  
> environment.  The
>    app requires some method to invoke a task and optional  
> arguments.  It may
>    or may not return a response message other that a status, it may  
> also
>    produce a new data product that can be referenced later by name.
>
>    Missing Concept:  Well, ...IRAF

As above, I don't view this as a good thing, at least in general. I  
actually do this via PLASTIC although not with IRAF, as does Mark  
Taylor, however we both use internal (privately defined and name- 
spaced) messages. I don't think we should add this capability to the  
default messaging layer because it represents a huge security and  
authentication & authorisation problem and the associated overhead  
will vastly complicate the specification. As I've argued in the past,  
the word 'simple' has to be our guiding watch word here. We aren't  
trying to invent a general messaging system.

Internal private (application specific) messages are the way this is  
approached in the current PLASTIC specification. I'd tend to hold out  
for this to continue to be the way such things are handled...

Indeed if you want to do the above I might even suggest the UWS  
specification from the Grid & Web Services group is better match to  
your needs than the specification we've been tasked to put together  
here.

Al.