TWiki
>
IVOA Web
>
IvoaApplications
>
ApplicationsMessaging
>
ApplicationsMessagingUseCases
(2007-04-27,
MikeFitzpatrick
)
(raw view)
E
dit
A
ttach
---+ 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. - IVOA.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. -- IVOA.MarkTaylor - 23 Apr 2007 ---++Use-Cases Not Handled (Eleganty) by PLASTIC <pre> 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 </pre> --IVOA.MikeFitzpatrick 27 Apr 2007 <br/> <!-- * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup -->
E
dit
|
A
ttach
|
Watch
|
P
rint version
|
H
istory
: r8
<
r7
<
r6
<
r5
<
r4
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r8 - 2007-04-27
-
MikeFitzpatrick
IVOA
Log in
or
Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Applications
Data Access Layer
Data Model
Grid & Web Services
Registry
Semantics
Interest Groups
Data Curation
Education
Knowledge Discovery
Operations
Radio Astronomy
Solar System
Theory
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback