Applications Messaging Uses

Below are some informal descriptions of the sorts of uses envisaged for application messaging.


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:

  1. 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.
  2. 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
  3. 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

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2007-04-27 - MikeFitzpatrick
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback