Message-id management revisited

[Alasdair Allan]

> no - this requires no new state and no processing that you're not  
> already
> having to do.  The implementation of the new method I'm suggesting  
> would, I think, be:
>
> sub getSenderMsgId {
>    my $self = shift;
>    my $private_key = shift;
>    my $hub_msg_id = shift;
>    my ( $public_id, $msg_id ) = split "_", $hub_msg_id;
>    $msg_id = "msg-id:" . $msg_id;
>    return $msg_id;
> }

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.

Erm... why do we have seperate sender-msg-id and hub-msg-id anyway?  
Someone remind me? It seems to be adding a whole level of  
complication, and I can't remember what we're getting out of it?

> (but note: if I understand correctly, your implementation would  
> *seem* to require for correct operation that the msg-id generated  
> by the sender starts with the string "msg-id:" - this is not good.

Nope. The hub-msg-id will always have a msg-id: infront of it, but  
the regexp just removes the msg-id: which my clients stick infront of  
their id string. It doesn't require that it's there. If it isn't the  
regexp doesn't do anything.

>  I think it's also vulnerable to sender-msg-ids which contain  
> underscores

On the other hand this is true. I need to fix that.

Al.