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@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2008-06-05Z11:04:58