Message-id management revisited
aa at astro.ex.ac.uk
Thu Jun 5 02:01:03 PDT 2008
>>> 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
>> argument, this would be my second choice. This simply exposes a
>> 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
> 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-
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.
More information about the apps-samp