Message-id management revisited

[Mike Fitzpatrick]

> 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