Message-id management revisited

[Mark Taylor]

On Tue, 10 Jun 2008, Mike Fitzpatrick wrote:

>     If I understand option 9, we now get rid of the translation
> method and instead
> give the sender the hub-msg-id?   So,  the sender now needs to know its
> sender-msg-tag to handle a reply() *as well as* the associated hub-msg-id so it
> can match up with a later status message?  (Note that status is one example,

Yes.  If (and only if) a sender may want to send or receive progress-like 
messages later then this proposal means that it needs to store two 
strings rather than one.  I concede that that is more effort, but I 
wouldn't call it a significant burden.  The translation method idea 
is much the same but means that such a client would need to call 
an extra hub method to find the second one of those strings - which 
I'd say was more of a burden, though again not much.


>    Note the original suggestion was that the final msg-id be simply a string
> composed of what the sender creates plus what the hub wants to add.  This

No Mike, this was not your original suggestion:

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:

i.e. there is nothing in the msg-id which is "what the hub wants to add",
it is all chosen by the client in accordance with certain rules, 
and that means that the hub cannot use it to store custom state. 
As soon as the msg-id contains something that the hub wants to add 
the problem arises of how the sender finds out what that is.

> appears to be how Mark is implementing it anyway, and there's nothing that
> prevents him from adding flags for sync/asynch and such to the hub bit, but
> we can keep state in the msg-id, avoid hub methods, multiple msg-id tracking,
> and absolutely everyone has a trivial way to find the sender-msg-tag,
> hub-msg-tag, and hub-msg-id.  What is so friggin' impossible about this!?

What is so friggin' impossible is that if the hub is adding bytes of
its own choice to the msg-id, then the sender can't know what the
msg-id is without additional measures, e.g. 4 (sender-tag -> msg-id
translation method) or 9 (msg-id is returned from call() methods).

I want to avoid going backwards on this.  We already have Thomas, 
Alasdair, Luigi and me in favour of 9.  Mike, if you can find support 
among other participants for a different one of the existing proposals
(or some new one) on this topic, we can continue the debate, otherwise 
I am going to go ahead with 9.

Mark

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