Apps Messaging - Semantics of a Message

Tue Apr 10 09:46:19 PDT 2007

Mike and John,

Following John's latest message, I'd like to back track a bit:

On Sat, 7 Apr 2007, Mike Fitzpatrick wrote:

> All I can say is that a "here's an image, do something' message to a
> msg-enabled IRAF is just asking for trouble.

Agreed.  There are a million different reasons you might want to
pass an image to IRAF.  The fragment-appending scheme is not going to
help you much in this situation.

>                                               What you describe is a
> data-sharing interface and not messaging where the messages have any real
> meaning or predictability for the user.

This is a very useful distinction to draw, and you're right: 
really data-sharing is what PLASTIC was designed for and has been 
most used for, and is something that the current PLASTIC developers 
are keen that they can carry on doing in any future messaging 
(or maybe "messaging") protocol.  It is not quite true to say that 
the messages don't have meaning or predictability for the *user*, 
but they may not do for the sending application - the effect of 
passing a message is dependent on the message content and on what 
the recipient application decides to do with it.  The user may have 
a good idea what this is, though in general the sending application 
may not.  This mode of operation is particularly effective in the case 
that the sending application has no idea about what other applications 
may be running or what capabilities they might have - a scenario which
is quite common in the current era of rapid simultaneous development 
of multiple VO-friendly applications.

It is becoming clear that there are two quite different types of job that
we want a messaging system to do.  As Doug said:

Doug Tody wrote:

> Most of the PLASTIC type scenarios seem to involve visualization tools
> which operate upon high level data objects such as images, tables, and
> so forth.  In general for this sort of thing I think a high level
> object-oriented approach is most promising (as with PLASTIC I think).
> That is, one merely sends an entire data object of some type to an
> app, either as a reference (e.g., URL) or in-line, with some general
> suggestion for what to do with it ("display", "load", etc.), and it
> is up to the app from there.  This makes the messaging very simple,
> and allows the full capabilities of the application to be utilized.
> 
> Another important case though, is where we have a powerful tool such
> as an image display service (DS9, Aladin, iraf ximtool, etc.) which
> has a more complex model defining things like image planes, associated
> world coordinate systems, display modes, etc.  In this case the client
> might want to command the tool, rather than merely send it high level
> data objects.  This is more the sort of thing that XPA/DS9 and XImtool
> do (also others such as the image viewer in AIPS++/CASA, and the
> IDL visualization tools).  This is also an important case, and can
> be very important in some cases, for example to drive visualization
> tools from a Python, IDL, IRAF, etc. script application.

For scenarios of the first type it makes perfect sense to say simply
"here's a table".  For scenarios of the second type, it does not.

It's not totally obvious that a single messaging system will serve
both purposes, and I think we should keep an eye on whether we're 
trying to produce one standard where two would be more appropriate;
however, as far as Mike's IRAF examples  go, I think something similar
to the way that PLASTIC currently works (and roughly consistent with 
both Mike's and John's detailed proposals of the last few days) 
can accommodate both types of task without much problem.
The first type of scenario is up and running in PLASTIC. 
As for the second:

Mike Fitzpatrick wrote:

>       For example, when I first listed the set.param and exec.task mtypes
> I had a particular case in mind of calling an IRAF task.  So the messages
>
>       mtype=set.param   args="imfunc.input    foo.fits"
>       mtype=set.param   args="imfunc.output   bar.fits"
>       mtype=set.param   args="imfunc.function sqrt"
>       mtype=exec.task   args="imfunc"
>
> could set the individual parameters and invoke the task  (in IRAF you
> can set a parameter as "<task>.<param>=<value>" on the command line,
> I realize imfunc.input looks like an mtype but it means the 'input'
> param of the 'imfunc' task).  This scheme works to call almost any task
> the same way.  If an image were a URL I could download it to a file and
> the above stays the same, but implementing 'image.fits.url#imfunc' means
> I need separate methods for each task I might call (rather than a generic
> callTask()),and things just overall get messy.  I'd point out that here
> we have 2 mtypes that let you access literally hundreds of tasks!!

this mode of usage is fine!  This is unlike anything we've done with
PLASTIC up till now, but I don't see any reason why the general ideas 
that we've been discussing over the last few days can't be used 
in this way.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/