Apps messaging - message content

[Doug Tody]

Hi All -

> o   Message content (possibly including use-cases).  Everyone
>     agrees that this is application-specific, can be high or low
>     level, that different schemes can be based on very different
>     approaches and concepts, and should be defined separately
>     from the basic messaging mechanism.

A few points on the issue of message content.


To the basic messaging system, the payload or content of a message
should be just an opaque block of data, of arbitrary size, up
to some fairly large limit defined by the message content type
or implementation.  It is described by the metadata defined by the
messaging model, but otherwise to the basic messaging layer, is merely
data to be passed on.

Somehow we need to describe the type of message content.  This should
probably be basic message metadata.  The version should probably be given
as well.

This could all be folded into the "mtype", but it may be better to
have two separate attributes, one for the specific message class
or type of the message instance, and one for the message content or
protocol type/version to which the message instance belongs.

The kind of apps that currently use PLASTIC might support only a single
type of message content, so this need not complicate things for basic
inter-tool communication, but it is needed to permit different levels
or approaches to application messaging, to support evolution of the
infrastructure, etc.

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.

Basically I think these are two different types of message content;
one probably wants to model them separately.  A single tool could
support both message content interfaces, hopefully based on the same
messaging infrastructure.

Interaction with remote applications can take many forms.  In a
distributed application one probably never wants to expose something as
low level as a button press up/down event via the messaging system.
Rather one defines some higher level abstraction, such as "read
cursor", or "read region", and the app interacts with the user to
generate a "cursor" or "region" object which is passed back to the
client.  This might be a type of RPC; a variation on it could be a
notify or property change event.

In general, requests do not need to be synchronous.  Another approach
is for most requests to be asynchronous, relying upon state to be
maintained in the application (image display tool or whatever), using
property change events (a type of Notify) to inform the client what
subsequently happens and whether the request was actually performed.
In many cases this is all that is needed.  For example, if the client
requests that the displayed frame be changed, it probably does not
have to know synchronously that the frame was actually changed,
rather a change value event on the "displayFrame" property might be
all that is required.

An important question regarding message content is to what extent data
can be included in a message.  It is not always possible to merely
refer to data objects in a message via a reference of some sort (e.g.,
a URL or file pathname): for example, the reference might not be valid
in the context of the recipient, or the object referred to might not
exist or might have been modified by the time the message is received
(messages are often time critical).  Hence it is important in general
to support both references, and inline content.  How to specify data,
which can be of arbitrary size and format, is an important factor in
specifying a message content mechanism.

 	- Doug