Re: Message-id management revisited

> I can think of a lot of different ways this could be addressed, with
> associated disadvantages. Amongst other possibilities:
> :
> 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 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 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?

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

> 8. do nothing
> - can't transmit progress information

      Not happy with this at all -- progress dialogs are accepted as good practice
in interface design and we can't assume there is only one long-running job active
or that only one app requested it.

     Option 2 totally avoids round-trips to the hub and lets all app know what the
msgid is trying to convey; option 4 is acceptable where the number of apps needing it is low and its use in the desktop-gui environment means there's no real burden; option 8 is something we might regret one day.

Cheers,
-Mike Received on 2008-06-05Z07:28:51