Apps Messaging - Semantics of a Message

[Mark Taylor]

Doug,

On Tue, 10 Apr 2007, Doug Tody wrote:

> 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

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.

For well-supported languages such as Java where someone will probably 
write a toolkit that may not be such a big deal.  However it makes 
the cost of take up considerably higher if you're working in an 
environment which is less well supported (Fortran, Python, Tcl, ...).
In PLASTIC, reducing this burden on application authors (at the expense
of effort made by hub authors if necessary) was one of our explicit 
design objectives; I think our perception has been that this low 
burden has paid dividends in widespread adoption.

I've made the point before that there are costs as well as benefits 
in designing a highly generic and flexible system; I'm not necessarily
saying that we shouldn't do it, but I do think we need to bear this
in mind.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/