Apps Messaging - Semantics of a Message

[Doug Tody]

On Wed, 11 Apr 2007, Mark Taylor wrote:

> I would much prefer to agree on a small number of mtypes which we know we 
> need, and augment the list on an ad hoc basis as indicated by emerging 
> specific requirements of applications which need to do particular jobs.

This is basically what I was suggesting as well; the "small number
of mtypes which we know we will need", is your basic object model for
interoperable inter-tool messaging.  After that, I suspect we begin to
transition to a different model closer to stateful interactions with a
specific tool/app (which is fine but it is more of a custom extension).


On Wed, 11 Apr 2007, Mark Taylor wrote:
> On Tue, 10 Apr 2007, Doug Tody wrote:
>> 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
> 
> What it simplifies is the messaging infrastructure (writing a hub).
> It pushes additional complexity to the client applications, which
> need separate layers for (a) receiving the message and (b) parsing
> its content.  They may need more than one of each if they wish to be
> able to operate in the presence of a variety of the defined message
> protocols, or a variety of the defined content models, that the
> flexibility allows.

Actually, this does not have to be the case, because a simplified
interface/protocol (as exposed by the "hub") can be provided for
inter-tool messaging.  Basically, the underlying messaging model and
infrastructure can be more sophisticated and usable for a wider range
of things, but a simplified interface/protocol could be provided for
the sort of whole-object messaging done with PLASTIC.  This simplified
interface might for example, support only one message content model.
This would appear to be integrated into the interface, from the client
applications point of view (basically the message content layer is
pushed down into the "hub" to provide this simplified interface).

To do more complex things, a different interface would be required,
but clients would not need to use this.  What we want to achieve, is
to allow those "plasticised" apps to interface to the more powerful
sort of messaging infrastructure required for large data processing
systems, so that they can be used without modification.

What is important is to get the underlying messaging model right.
However, this is only a problem for the system designers.

 	- Doug