Applications Messaging Uses
Below are some informal descriptions of the sorts of uses envisaged for application messaging.
PLASTIC
These are some of the current uses of PLASTIC:
Instruct an app to:
- load a VOTable
- load a FITS image
- load a spectrum
- select/highlight a subset of points in a scatter plot
- create a new table from a row subset
- highlight an object in one view as the mouse hovers over the same object in another view (in a different application)
- work on a selection of a columns in a table (for instance, run a kmeans clusterer on only some columns/attributes)
- load a (registry) VOResource description and do "something appropriate"
- show a particular area of sky
- display a group of clusters (in the datamining sense) in different colours (not yet implemented)
- ask another application to display a DSS preview image of a given region of the sky
- display the location of a VOEvent
Desktop-2-Desktop PLASTIC
I'm currently using desktop-2desktop PLASTIC to pass messages from a remote server machine running a daemon, which may have interesting things to tell/show a user, passing message through a PLASTIC Gateway (cf the Garching VOTech meeting hack-a-thon), to a "local" desktop where if the user is running their gateway (and appropriate display/visualisation applications) the data is then displayed for them to look at, if no gateway is running at their end the messages from the daemon are simply ignored. In other words the user can keep up with what their backend software is doing if they want to, or ignore it and let it get on with things if they're confident it's doing the right thing.
-
AlasdairAllan - 06 Apr 2007
User-controlled Data Exchange
One of the core uses of PLASTIC messaging at the moment is exchange of high-level data objects (tables, images, spectra) between applications as directed by a human user as part of his/her interaction with said applications. The messages used for this are covered by the "current uses" section above, but for the sake of definiteness here is the kind of sequence in which this messaging typically takes place:
- An application X identifies the URL of a VOTable from somewhere (e.g. cone search). It knows that it is a VOTable. It wishes to provide the facility for passing this to some other software component, which may be able to do something interesting with VOTables.
- X finds out from the hub which other currently-running applications can do something useful with a VOTable, and provides a list of these to the user (e.g. a popup menu). Some of the applications which declare their ability to deal with this kind of data may provide additional human-readable information about what they will do with them, and/or provide multiple options in this regard. So for instance A's "do something with this VOTable" menu might look like:
- Aladin: load
- TOPCAT: load
- Y: crossmatch
- Y: convertToFITS
- The user may select one (or occasionally more) of these options and initiate sending the message thus specified. X may or may not receive some acknowledgement from the receiving application(s) that the transfer has succeeded, and may or may not decide to act on any such acknowledgement.
--
MarkTaylor - 23 Apr 2007
Use-Cases Not Handled (Eleganty) by PLASTIC
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.
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.
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).
4) a) I want to display a 2-D image to any application capable of rendering
it on the screen for me.
b) I want to do the same but only if the app can accept a URL insstead
of a local file name,
c) I want to display an image to a specific frame/plane of the
app so I can load it for an animation/blinking.
d) I want to display an image to a specific region of the image display
window (e.g. as part of a detector mosaic)
Missing Concept: Ability to query and/or exploit specific capabilities
of an application.
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.
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
--IVOA.MikeFitzpatrick 27 Apr 2007