Message-id management revisited

[Mark Taylor]

On Fri, 6 Jun 2008, Alasdair Allan wrote:

> 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

What I took Mike's suggested progress MType to be was something sent by 
the recipient back to the sender indicating how progress was getting on,
so yes it is the receiver broadcasting updates to the sender.
But actually, it doesn't matter - in general we might want to send 
messages in both directions discussing a previously-sent message.

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

If the two ends were going to refer to a previous message using its
hub-msg-id, you would be right, and this would require a lot of extra
work by the hub.  However, the point is, if the two ends need to 
reference a previously sent message, they both use the sender-msg-id
instead - the sender has this already, and the recipient can find it
using the hub translation method I proposed before.  The implementation
of that method is easy (as I showed with reference to your code), 
because it's something that the hub has to know how to do in any case.

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