Message-id management revisited

[Mark Taylor]

On Fri, 6 Jun 2008, Douglas Tody wrote:

> A simple solution might be to allow the messaging system to add
> additional properties to message headers, which the client is required
> to preserve if it responds to a message.  These would be private
> to the messaging implementation; the spec merely says how they are
> stored in the message.  I suspect this would be an important capability
> to provide.  It would seem to cover the use-case you mention.
>
> The client's message-id however, is merely a tag known to the client
> which it may use to keep track of messages, for example to associate
> an asynchronous response with a request.  There is probably no reason
> to require a particular format for this: <client-id>-<msg-tag> is a
> reasonable suggestion, but in general the format used might depend
> upon the client messaging API.  The messaging system need not use this
> property at all, it could instead be part of the application messaging
> protocol.  (This is all sounding rather similar to email headers which
> deal with both transport as well as arbitrary application-defined
> semantics).

This is pretty much what we're doing, except that the additional
properties added by the messaging system are not (in the terms used
by the document) "inside the message", but they are transmitted 
alongside it.

> It is not clear that any state is required in the messaging system,
> except to maintain information on open client connections, per-client
> subscriptions, accounting statistics, and the like (ignoring state
> associated with services which are bundled into the "hub").

that's right.

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