>>> 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.
Ok, such is life. But... Do you mean the above, option 4?
Up till now this hasn't been actually been functionality the Hub already had to implement. It merely had to generate a hub-msg-id that was resolvable (in some way) to the sender-msg-id. There was no requirement for the Hub to have to serialise this mapping.
For instance I did this,
my $hub_msg_id = $public_id . "_" . "$msg_id";
$hub_msg_id =~ s/msg-id://;
$hub_msg_id =~ s/client-id:/msg-id:/;
where the public id is the $public_id of the originating app and the $msg_id was the sender-msg-id. Turning a $public_id = "client- d:dhgTjfv8jTYH7fg56kJL" and $msg_id = "msg-id:hhjYU6ttgR45dgHHcCvG" to this $hub_msg_id = "msg-id:dhgTjfv8jTYH7fg56kJL- hhjYU6ttgR45dgHHcCvG".
So when it got a reply( ) all I did was this,
my ( $public_id, $msg_id) = split "_", $hub_msg_id; $public_id =~ s/msg-id:/client-id:/; $msg_id = "msg-id:" . $msg_id;
no state was necessary. Suddenly we're adding huge amounts of overhead to the Hub. It has to keep track of which message arrived from which sender, where it got dispatched to, it has to figure out when these expire (so it can clean out its backend cache of such things). Suddenly, there is all this overhead. I see absolutely no advantages of adding all this extra book work.
Al. Received on 2008-06-05Z11:01:29