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.