Message-id management revisited
m.b.taylor at bristol.ac.uk
Thu Jun 5 01:42:58 PDT 2008
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
> - 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
>> 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
OK then, if nobody else expresses an opinion (Al your voice is noted
but currently outvoted) let's go with 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