Message-id management revisited

[Alasdair Allan]

>> Okay, maybe I'm totally misunderstanding what's going on here, but  
>> I don't
>> see why somebody that wants to make a status call on a process  
>> will know the
>> hub-msg-id that got sent to the application. The originating  
>> application
>> sends a message with a sender-msg-id, which gets pushed to the  
>> hub, which
>> pushes it to the recipient with a new hub-msg-id. When the  
>> recipients wants
>> to reply( ) it replies to the hub with the hub-msg-id, which  
>> forwards it onto
>> the originiator with the sender-msg-id in the response. At no time  
>> does the
>> originiating application know the hub-msg-id. So the only way for the
>> originating application to make a status call is to ask the hub to  
>> ask the
>> recipient about the message sender-msg-id. Which means the hub now  
>> has to
>> keep state on the mappings between the sender-msg-id and the hub- 
>> msg-id,
>> because the recipient only knows about the hub-msg-id tag.
>
> I can't follow your logic here.  The sender knows the sender-msg-id  
> because it selected it in the first place.  The receiver knows the  
> hub-msg-id because it's delivered with the message, and given the  
> translation method above it can find out the sender-msg-id from that.
> So the two ends can agree on a single identifier (the sender-msg-id)
> which allows them to work out what message they are talking about.

Yes, but... it's the SENDER that is going to ask for updates from the  
receiver, not the receiver broadcasting updates to the sender isn't  
it? So the reciever is not the one that will ask! Although the  
reciever does indeed know the hub-msg-id as you've said above. The  
sender knows the sender-msg-id, not the hub-msg-id. But now the hub  
must know the mapping from the sender-msg-id to the hub-msg-id so  
that, when the sender sends out a message to ask for a status update  
from the reciever, it can tell it.

> Alternatively, to confuse matters further, here is another option  
> to add to my earlier list, which I think might prove preferable:
>
>   9. hub-msg-id is returned from existing call() methods
>
>      The existing call methods
>
>          void call(string recipient-id, string msg-id, map message)
>          void callAll(string msg-id, map message)
>
>      are left exactly the same (except I'm going to change the name of
>      of one of the parameters for clarity), except that they now
>      return the hub-msg-id:
>
>          string hub-msg-id = call(string recipient-id, string  
> sender-msg-id,
>                                   map message)
>          string hub-msg-id = callAll(string sender-msg-id, map  
> message)
>
>      Everything will work exactly as at present, except that senders
>      which want to know the hub-msg-id (e.g. because they are  
> expecting
>      progress messages) will have to wait for the call() method to
>      round trip.  Senders which don't care can dispatch the call()
>      without waiting around for the return value as at present.

Seems reasonable.

Al.