ISSUE: Message-id management

[Mark Taylor]

On Tue, 13 May 2008, Mike Fitzpatrick wrote:

>> I will try to clarify that footnote as you suggest.  Note however that
>> the people who need to worry about this point are hub implementors
>> rather than client implementors, so probably not too novice.
>
> To my way of thinking, "implementing SAMP" includes Hubs and clients.
> Novice or not, the current words don't do justice to what a separate
> hub-msg-id offers without some more explanation.  My 'reflections'
> included cases where the hub-msg-id had a timestamp to allow
> msg expiration, or encoded-mtypes to deliver only most-recent
> messages.   If you can claim checksums, give me at least this
> (especially since I'm agreeing with you 8-)).

Mike,

I've amended the text as follows:

    There is no requirement on the form of the {\em hub-msg-id\/}
    (it is not intended to be parsed by the recipient), but it must be
    sufficient for the hub to pair messages with their responses reliably,
    and to pass the correct {\em sender-msg-id\/} back with the response
    to the sender\footnote{
       One way a hub might implement this is to generate {\em hub-msg-id\/}
       by concatenating the sender's client id and the {\em sender-msg-id}.
       When any response is received the hub can then unpack the accompanying
       {\em hub-msg-id\/} to find out who the original sender was and what
       {\em sender-msg-id\/} it used.  In this way the hub can determine
       how to pass each response back to its correct sender without
       needing to maintain internal state concerning messages in progress.
       Hub and client implementations may wish to exploit this freedom
       in assigning message IDs for other purposes as well,
       for instance to incorporate timestamps or checksums.
    }.

Hope that looks OK to you.

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