Maybe I'm just being unusually dense this week, but I'm still not sure what problem option 9 is meant to address.
For the original status mtype the intent was that the recipient
would occasionally
send a progress message to the sender saying what was going on. To do this is
needs the sender-id (which it gets from the receiveCall() method) and then the
original sender-msg-tag so the sender will know which request is being updated
(it gets this from the hub translation method). If the recipient also
does a reply()
they use the hub-msg-id and the hub takes care of finding the
sender-id and returning
the original sender-msg-tag.
If I understand option 9, we now get rid of the translation
method and instead
give the sender the hub-msg-id? So, the sender now needs to know its
sender-msg-tag to handle a reply() *as well as* the associated hub-msg-id so it
can match up with a later status message? (Note that status is one example,
the problem refers to any case where a message might refer to an earlier
request). In Al's version where the sender asks for updates with a get.status
(or whatever), it would then need to send the hub-msg-id and require the
recipient to keep track of this as well (which is why the pattern
worked the other
way).
My vote is moot at this point, but this seems like more work for the apps to allow something simple.
Note the original suggestion was that the final msg-id be simply a string composed of what the sender creates plus what the hub wants to add. This appears to be how Mark is implementing it anyway, and there's nothing that prevents him from adding flags for sync/asynch and such to the hub bit, but we can keep state in the msg-id, avoid hub methods, multiple msg-id tracking, and absolutely everyone has a trivial way to find the sender-msg-tag, hub-msg-tag, and hub-msg-id. What is so friggin' impossible about this!?
-Mike Received on 2008-06-10Z20:17:32