Apps Messaging - Semantics of a Message

[Mark Taylor]

Doug,

On Thu, 12 Apr 2007, Doug Tody wrote:

>>> What is important is to get the underlying messaging model right.
>> 
>> I'm not trying to be funny, but: why?  Leaving aside any difficulties
>> about coming to agreement on the details of such a model, can you
>> explain what you see as the practical advantages of having a "right"
>> messaging model ...
>
> This is extremely important, as it will be the basis for all
> the message-related protocols which are layered on top of it,
> and the basis for all messaging-related software implementations.
> A model like this tends to get built into all software which uses it.
> It defines the basic semantics of how you do messaging.

The benefits that you list sound to me more ideological than practical.
As you can probably tell, I am somewhat (though not totally) sceptical
that designing a multi-layered model-based abstract generalised
messaging architecture followed by separately designing multiple
alternative prescriptive specifications of how to implement this,
as opposed to starting with the specifications of what applications
need to do in order to talk to each other, is the best way to go
about things.  Such additional layers of abstract design *may*
pay dividends, but only if it turns out that new messaging
situations arise which both are difficult/impossible in the basic
profile and must/should share part of their specification
with it, and it's not clear to me that that will be the case.
Such multi-layered approaches also face dangers not presented by
one-size-fits-all designs, such as the possibility of partial
implementations and of "compliant" implementations or messages
which are mutually incompatible.  Whether I am being admirably
pragmatic or woefully short-sighted here will only be answered
by future developments.

However, we're probably not going to progress further on this by
continuing to argue about it.   Some people in the debate are more
concerned with how the data model underlying messaging is formulated
(with a view to permitting various different implementation profiles
as needs arise in the future), and others are more focussed on
sorting out the nuts and bolts of what an application has to do
in order to participate in a messaging or data-sharing conversation,
in particular on issues like bootstrapping a connection with the hub
and selection of a wire protocol.  To some extent these concerns are
orthogonal (though of course the former will influence the latter),
so I think we should be able to come up with something satisfactory
to both sets of interests without too much disagreement.

*If* we go down the route of revolution (scrapping PLASTIC as it stands
and replacing it with something which can do similar things but which
may have advantages such as more flexibility and securer theoretical
underpinnings) rather than evolution (incremental modifications of
the existing PLASTIC standard to allow it to do new things where new
capabilities are required), then I am happy that this is done along
lines similar to those that Mike and Doug are advocating, although
there are still matters of detail to address.  I agree with the comment:

> Also: this does not have to be all that hard.  I don't think we are
> far from having such a basic messaging model.  What Mike outlined
> earlier, with some more work along the lines of these discussions,
> would probably work for our applications (not just for high level
> inter-tool messaging).

as far as it applies to the task of specifying a standard from scratch:
what will require some effort however is reworking existing code in
PLASTICised applications (and, less importantly, in hub implementations),
and organising things such that the changeover between the existing
and future messaging systems does not leave users with tools on
the desktop unable to to communicate because they speak different
messaging protocols.

The opinions in this message are basically my personal ones; I've
got some idea, but I'm not sure, how far they are shared by other
active and passive participants in the debate, and I don't wish to
push them if they are not widely shared.  It might be a good
point for such participants who have an interest or opinion
(particularly those who hope in the short or long term to adopt
whatever it is we end up agreeing on) to provide input about
where they stand on these issues.

Mark

P.S. I should mention that I will be away all next week; I understand
      that John Taylor and Alasdair Allan will also be busy.

-- 
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/