On Fri, 6 Jun 2008, Mark Taylor wrote:
> I am arguing for something very similar to this: the only difference
> is that instead of the msg-id form being fixed as <client-id>-<msg-tag>,
> the hub can choose how it builds its msg-id from the <client-id> and
> <msg-tag>. The only additional complication that this causes is that *if* the
> sender needs to know the msg-id that the hub has generated
> (and it is rare that it will - it's not required simply for matching
> messages with responses) then it will have to get it from the hub, e.g. using
> a translation method or waiting for a round trip at send time. As in the
> above scheme, the hub does not need to maintain any per-message state (except
> for synchronous messages, which is not what we're talking about here).
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).
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").