Message-id management revisited
m.b.taylor at bristol.ac.uk
Wed Jun 4 04:50:01 PDT 2008
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
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
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 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