Message-id management revisited
m.b.taylor at bristol.ac.uk
Mon Jun 9 03:51:08 PDT 2008
We should draw this point to a conclusion, and then I'll post my
draft of the SAMP doc to this list for final comments before uploading
it to the IVOA document server as a Working Draft.
Alasdair has gone quiet for a few days, which I interpret as meaning
he is prepared to accept my argument (or at least my assertion) that
none of this will lead to any significant complication for hub
implementations, and in particular that no per-message hub state
or bookkeeping will be required.
My summary of the current state of the discussion is that my
4. hub provides hub-msg-id -> sender-msg-id translation method
is an acceptable compromise for everyone. Alasdair and I are also
9. hub-msg-id is returned from existing call() methods
(see last part of http://www.ivoa.net/forum/apps-samp/0806/0129.htm).
I think this is slightly tidier - Mike if you agree I will do 9,
otherwise I will do 4.
I also suggest that I rephrase the wording and API description slightly,
so that instead of "sender-msg-id" and "hub-msg-id" we talk instead
about a "msg-tag" and a "msg-id". I think this is less confusing and
makes more sense, since the hub-generated part is a unique identifier,
but the sender-generated part is just a string which the sender
associates with the message, which (according to how the sender
wants to do it) may or may not be unique.
Having done this I can add Mike's suggested progress messages
(see next post for more detail on this).
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/
More information about the apps-samp