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.