Message-id management revisited

[Douglas Tody]

I have been trying to stay out of this endless discussion but see this
one is coming up again...

On Wed, 4 Jun 2008, Mike Fitzpatrick wrote:

> >  2. sender generates single msg-id with fixed form <client-id>-<msg-tag>
> >        (this was Mike's original proposal)
> >      - hub can avoid maintaining *essential* state, but if it wants to
> >        keep track of other per-message info (e.g. timestamp, checksum,
> >        ...) it will need to store it internally.  Also need to worry
> >        about what happens if the sender does not follow the requirement
> >        for how the id is generated - better to have an interface in
> >       which it's impossible to do the wrong thing.
> 
>     This is still my first choice (surprised?).  Because:

This was my original suggestion as well (long ago).  Since the
client has a unique client-id (returned by the hub at connect time)
it is trivial to generate a unique message-id, avoiding a round trip
to interact with the hub when sending a message, and automatically
ensuring that the client knows what any response messages refer to.
There is no need for the hub to keep track of message sequences
(whatever happened to that brag about the hub not trying to do
transactions etc.?)


On Thu, 5 Jun 2008, Alasdair Allan wrote:

> [...] no state was necessary. Suddenly we're adding huge amounts of
> overhead to the Hub. It has to keep track of which message arrived
> from which sender, where it got dispatched to, it has to figure out
> when these expire (so it can clean out its backend cache of such
> things). Suddenly, there is all this overhead. I see absolutely no
> advantages of adding all this extra book work.

Agree completely.  All the "hub" should be doing is delivering
messages, aside from any built-in services it provides on the side
for per-client property storage, naming services, or whatever.
The more complex and application-specific the semantics built into
the messaging core, the less useful it will be to clients that do
not fit the specific interaction pattern one has in mind initially.
Application specific interaction patterns can be layered upon a
general messaging core.

	- Doug