Applications Messaging Standard

[Doug Tody]

Regarding this issue of the "hub", or "message bus", etc. - these are
all just examples of some form of messaging infrastructure.  Words like
"hub" or "bus" merely imply a certain type of connection topology
that the messaging infrastructure implements.  They make it easier to
talk about these things in concrete terms, but the terms are imprecise
and possibly misleading so we need to be a bit careful using them.

If we try to think about this a bit more formally, what we need to
define is merely an "interface" (e.g., in the sense of a modern
language such as Java etc.) which provides certain well-defined
operations with well-defined semantics.  An "implementation" like
the PLASTIC hub merely implements this interface.  So long as some
software implements the interface in a compliant fashion, it doesn't
matter how it is implemented.  A given implementation may well support
additional, completely different interfaces simultaneously, or the
semantics may be a superset of what the standard defines.

In addition to a standard interface we need to define at least one wire
protocol to be used to talk to the an implementation of the standard
messaging interface.  If for example this protocol is socket-based,
we need to specify in socket terms what the protocol is (e.g., as in
Pat's example).  If the protocol is partly file-based, then we need
to specify that instead.  This protocol is largely a separate matter
from the formal messaging interface, which could be implemented over
multiple wire protocols.

The messaging interface will probably only provide some mechanism
for expressing a message, and transmitting or receiving a message.
The message _content_ used to talk to specific applications is then
another aspect of the standard.  For the most part, the message
content is probably independent of the specific messaging interface,
although certain concepts such as message classes and so forth will
probably need to be common.

Finally, when it comes time to use this in a client application,
ultimately there is probably going to be some sort of API which
client programs actually use.  If all we do is specify things to
the level of the wire protocol, the applications programmer is still
likely to write their own API on top of, e.g., XML/RPC or whatever.
One certainly wants to standardize the protocol so that this sort of
thing is possible.  However, real-world users - for example writing
Python apps (or IDL, IRAF, etc.) - will generally not very much mind
if someone hands them a ready made module which implements the protocol
and provides a nice easy to use API.

I think these are all important elements of the inter-tool messaging
facility we are talking about.  They all need to be carefully defined,
and should not be all muddled together.

 	- Doug