Apps Messaging - Twin track?

[Brian Walshe]

Hi,

For use case 1, I'd wrap it in the old code in python (but that's probably 
just because I hate fortran so much). Also, I think some of the tasks in use 
case 4 could be solved with message annotations.

Cheers,
Brian.

----- Original Message ----- 
From: "Mike Fitzpatrick" <mjfitzpatrick at gmail.com>
To: <apps at ivoa.net>
Sent: Friday, April 27, 2007 11:08 AM
Subject: Re: Apps Messaging - Twin track?


> I've posted some use cases I don't think PLASTIC solves on the
> twiki at
>
> http://www.ivoa.net/twiki/bin/view/IVOA/ApplicationsMessagingUseCases
>
> To be honest, with painful contortions I could probably do each of these
> (and will likely think of others) but that isn't the point here.  I'll
> include the
> text here for easier rebuttal.
>
> -Mike
>
> 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
>