Message-id management revisited

[Mark Taylor]

On Thu, 5 Jun 2008, Mark Taylor wrote:

>>>  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.
>
> OK then, if nobody else expresses an opinion (Al your voice is noted
> but currently outvoted) let's go with this.

on further thoughts, another option would be to provide this
hub-msg-id -> sender-msg-id translation facility via an administrative
MType which the hub MUST or SHOULD support.  This would avoid 
introducing clutter into the API itself, and provide a sensible
extensibility route for hubs which want to provide other useful 
data along similar lines.  I don't have strong feelings either way.

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