Message-id management revisited

[Mark Taylor]

On Tue, 3 Jun 2008, Mike Fitzpatrick wrote:

>  app.status.progress           msgid,str       progress string
>  app.status.progress.percent   msgid,float     percentage completed (float)
>  app.status.progress.timeLeft  msgid,int       est. time remaining (sec)

oof.  These get us back into deep water.

Progress messages are a good idea, but...

As the messaging is currently set up, the recipient does not use the
same msgid as the sender does to identify a given message - the
sender has the sender-msg-id and the recipient has the hub-msg-id 
and they are probably not the same, as described in the Asynchronous
Call/Response part of the "Sending and Receiving Messages" section. 
So these progress messages won't work (the recipient won't know 
which message the sender is referring to) unless there is some 
mediation by the hub to match the recipient's msgid with the 
sender's one.  The same applies to any other MType which needs to
refer to a previous message (an abort MType springs to mind as 
another possibility).

Yes this is a consequence of the scheme in which hubs and senders
get to choose their own msg-ids which I argued for and Mike was,
at least initially, against - see the ISSUE: Message-id management
thread.

I can think of a lot of different ways this could be addressed, with
associated disadvantages.  Amongst other possibilities:

   1. sender generates single free-form msg-id
       - means that hub does not have control over ID form, so can't use
         it to avoid having to maintain state internally

   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.

   3. hub generates single free-form msg-id
         (this is like what happened in PLASTIC, but Doug raised the issue
          of eliminating unnecessary round trips)
       - has to return it to sender from call() method, meaning that
         message call (though not message notify) requires a round trip.
         Also means that sender does not have control over ID form,
         so sender can't use it to avoid maintaining state internally
         (less serious problem than for hub).

   4. hub provides hub-msg-id -> sender-msg-id translation method
       - OK but slightly messy

   5. receiveCall() method passes sender-msg-id as well as hub-msg-id
       - OK but slightly messy.  Doesn't sound so bad if you rename
         sender/hub-msg-id as sender/hub-msg-tag or something.

   6. send progress info as a variant of hub call reply() instead of via MType
       - confusing - better if reply() just does one thing

   7. send progress info via a new hub call progress() similar to reply()
            instead of via MType
       - messy and less extensible - might want to do something other
         than progress involving msg-ids.

   8. do nothing
       - can't transmit progress information

I think I'd favour, in order: 5, 3, 4.  Anyone else?

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/