Apps Messaging - Semantics of a Message

[Mike Fitzpatrick]

Hi Al,

> A good start here, and I'll reply to the rest of your message later,
> but to kick off the discussion I'd like to take issue with the way
> you've conceptualised what the messages we're going to pass actually
> mean...

This is why I started by saying the list would 'suffer the same debate..."
Any list was gonna be a target so I just tried to cover the different things
we (I specifically) might do with the system.   Conceptually I wanted to
preserve the idea of a NOTIFY, REPLY and REQUEST "type" of message
and recognized the REQUEST would be the most controversial.
       I agree these should be the most common, and high level, kinds of
messages.  However, what I had in mind is that an app that connects and
claims to support a specific message could use this to advertise a specific
capability (consider for example an app that queries for these capabilities
and can dynamically build a menu of options).  There is also a logical diff-
erence between e.g. what image.histogram and table.histogram might
require or produce, a simpler 'histogram' message is more general but also
too general.

> >       event.*                         UI event messages
> >               :
>
> I really fundamentally disagree that we should be dealing with UI
> level messages, conceptually you're thinking us into a box here. I
> think the messages should deal with higher level concepts, i.e. "Here
> is an image, do what you want with it" level rather than, "The user
> pushed button A" level.

This was probably an extreme thing to put on the list, and should probably
be one of the "unregulated" messages if at all.  What I had in mind was an
IRAF use-case where a task like IMEXAMINE can do many different things
depending on the keystroke typed at a given position (also the reason for
the 'exec.task' thing).  So, after displaying an image and exec'ing the task,
a series of keypress events could be used to create contour plots, radial
profiles, etc.


>
> >     Request (response required)
> >       set/get                         Set/Get property messages
> >           info
> >           param
> >           property
> >           capability
> >           appName
> >           result
> >           filename
>
> Erm, this opens a whole can of worms. I must admit for the internal
> message system for eSTAR I have gone down this route as eSTAR
> epitomises a case where a bundle of ((very) stateful webservices is
> needful. However PLASTIC gets away without carrying state around at
> all (or at least you can design your app not to care). Can you give
> me a use case where we need to ship state around in this manner?

get.info      get the iconURL for an app a la PLASTIC
set.param  tell a task what the default SIAP search size is
set.property   set a 'timeout' property for delivery of msgs to an app
get.capabilty   request a list of supported mtypes from an app
get.appName    obvious
get.filename    get the filename associated with a msg 'refID'

Note there are parallels to some of what the PLASTIC API does.


> >       load/save                       File operations
> >           :
> Not sure how you envisage this working. One application tells another
> to save something? That very much depends if both can see the thing
> the first is talking about, which isn't necessarily a given.

One app tells another to select a set of rows based on some expression
or an explicit list.  Then, tell the app to save that subset to a new file.  Or,
load two tables, crossmatch and save the result.  How/whether a 'save'
message could be implemented is up to the app, but I can see wanting
to do it.


>
> >       plot.*                          Vector Graphics capabilities
> >           table
> >           rows
> >       display.*                       Image Display capabilities
> >           image
> >           URL
> >       select.*                        Table selection capabilities
> >           rows
> >       highlight.*                     Object highlighting capabilities
> >           position
> >           rows
>
> I'd actually like to go with a much looser conceptual design, so
> "Here is an image" and "Here is a table" and "here is a position"
> rather than "Display an image", "Plot a table" and "Highlight a
> position". That way we're really far more flexible, the application
> receiving the message can decide what its best designed to do with
> the data rather than being instructed to do a specific thing.

There is nothing in these that prevents an app from doing whatever
it likes in response to the message, but like I said the specificity
has the advantage of advertising something that both a machine
can parse easily, and a human developer can interpret as probably
doing what is wanted.  An app can simply register a "display.*"
capability without saying specifically what kinds of display it will
do, VOPlot could register with "plot.*" and then maybe it's just a
crapshoot for the sending app whether the user gets something
reasonable.

> .....For instance under the above are
> we going to send a message to "display.image" and
> "highlight.position" to one visualisation application, and then a
> different set of messages to another subtly different application
> that doesn't even have a UI perhaps, but would be interested in
> getting an image with an (user defined as interesting) position
> attached.

That's up to the sender.  One could send display.image to a
specific image display task, but send the 'highlight.position'
to the Any recipient in which case the display task and the
UI-less subtle app can do whatever they do.

This discussion of the specific messages is good and necessary
but perhaps a separate thread.  For the moment I'd like to focus
on whether the idea of a UCD-like 'mtype' is worth pursuing or needs
more development.  Once we agree on that we can fight over the
vocabulary.


-Mike