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. Received on 2007-04-29Z20:11:34