Message-id management revisited

[Mark Taylor]

Hi Mike,

On Wed, 4 Jun 2008, Mike Fitzpatrick wrote:

>>  2. sender generates single msg-id with fixed form <client-id>-<msg-tag>
>>        (this was Mike's original proposal)
>>      - hub can avoid maintaining *essential* state, but if it wants to
>>        keep track of other per-message info (e.g. timestamp, checksum,
>>        ...) it will need to store it internally.  Also need to worry
>>        about what happens if the sender does not follow the requirement
>>        for how the id is generated - better to have an interface in
>>       which it's impossible to do the wrong thing.
>
>    This is still my first choice (surprised?).  Because:
>
>    - If the sender/hub id strings are truly opaque as was initially
>      argued, then there is no wrong way for a client to generate the ID, it's
>      the hub that concatenates the values to form the final string.  The

I understood that your original intention was for the sender to do 
the concatenation (hence your earlier concern about the sender 
needing to know its own client-id).  If the sender sends its part 
and the hub forms the actual message-id by concatenating it to the 
sender-id, then yes there is no wrong way to do it - that would 
be better, and would remove the second of my concerns above.

>      value of the hub creating a second (perhaps concatenated, perhaps
>      not) opaque string as a separate ID is dubious (in general, in the way
>      Mark intends to use it I think its a variation on this theme but does no
>      harm).
>    - If the final string might contain something useful like a checksum as
>      was later argued, then why not let all apps in on the format so they can
>      parse out the useful bits as they see fit.  We now have a case

The reason is that things like checksum/timestamp/whatever-I-think-up-
next-week are implementation details.  They are not things that I am
suggesting we formalise in the specification, but things which 
individual hub implementations may privately decide they want to encode.
So there is no public definition of such a format to let clients in on.

> where we want
>      the original sender-id, is it a stretch to think we might later want the
>      timestamp/checksum/whatever-the-hub-does later when we'll need to
>      revisit this same issue?
>    - I really don't see the harm in recommending a format for the id
> string.  Is
>      this really more onerous for the hub/client developer than specifying the
>      hub methods or message format?

It's not the onerosity(?) that I'm worried about, its removing the
ability to exploit the freedom to choose a format for 
implementation-specific purposes.

>
>>  4. hub provides hub-msg-id -> sender-msg-id translation method
>>      - OK but slightly messy
>
>       Should there be a lack of unanimous epiphany regarding the above
> argument, this would be my second choice.  This simply exposes a functionality
> the Hub must already implement in order to handle a reply, and it's a really
> small number of apps that would need this as a way to get the sender-id to
> send a progress message.  The concern then is that it opens to door to
> requiring similar methods to get other useful data from the id string
> as mentioned
> above.

OK then, if nobody else expresses an opinion (Al your voice is noted
but currently outvoted) let's go with this.

Mark

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