Apps Messaging - Semantics of a Message

[Doug Tody]

On Tue, 10 Apr 2007, Mark Taylor wrote:

> To respond to Doug's comment about wanting various alternative argument
> transport formats, this could be only one (the default?) of several possible 
> argument transport formats.   For instance instead of
> passing individual arguments in this way you could have a single
> _argblock attribute which passes a packed data structure containing
> the information.

I just want to amplify this point.  It appears that everyone agrees
that it is a good thing to separate the messaging mechanism from
the message content; the messaging infrastructure shouldn't know or
care what is in the message, it just delivers it.  We can go one step
further and specify that the infrastructure just delivers the message
payload as an opaque blob of some sort, and it is up to another layer
of software to compose or interpret the message.  All that is required
is to specify the message content model, and version number.

While this may sound complicated, in fact it can simplify messaging
quite a bit, as it becomes possible to implement the basic messaging
system without having to specify the message content (many existing
messaging systems work this way).  Furthermore, since the message
content becomes a separate concern, one can specify a simple message
content model now expressly for simple inter-tool messaging (as
with PLASTIC), without having to solve the more general problem.
This simple content model might be only text-based, with keyword-value
pairs expressed as strings, or whatever.  If later one needs to do
something more sophisticated, such as send binary data to an image
display program, then a separate message content model can be defined,
which could re-use the same message transport.

What this means is that stuff like MTYPE, sender, message ID, the
content model/type ID, etc., are all part of the underlying messaging
model and basic messaging infrastructure.  Everything having to do with
the message content is a separate concern.  Like the content model,
the messaging protocol and any application libraries can be simplified
as well, and optimized for a specific application such as simple
inter-tool messaging.  So long as these are based upon a standardized
messaging model it should be possible to define a simple API which
is adequate for a certain class of applications (as with PLASTIC),
yet provide a range of messaging implementations which support this,
ranging from a simple hub to a future emulation interface built on
top of a more sophisticated third party messaging infrastructure.

Hence in this view what we have are the basic messaging model,
specifying the message attributes and available delivery semantics,
one or more message content models, specifying the message payload, and
one or more messaging protocols, specifying how a client application
interacts with the messaging infrastructure.

 	- Doug