DJabberd-MUC Fix (was Releasing 0.84)

[Martin Atkins]

Jeremy Lawler wrote:
>> diff --git a/lib/DJabberd/Connection/ClientIn.pm
>> b/lib/DJabberd/Connection/ClientIn.pm
>> index 3942977..3c2d830 100644
>> --- a/lib/DJabberd/Connection/ClientIn.pm
>> +++ b/lib/DJabberd/Connection/ClientIn.pm
>> @@ -143,6 +143,13 @@ sub close {
>> If you disconnect quite unexpectedly, you will not appear as
>> disconnected on muc room.
> 
> My approach to the same problem:
> 
> DJabberd-MUC/lib/DJabberd/Plugin/MUC.pm
> 29a30,37
>>     my ($self, $vhost) = @_;
>>     $vhost->register_hook("ConnectionClosing", sub  {
>>       my (undef, $cb, $conn) = @_;
>>       my $bj = $conn->bound_jid;
>>       foreach my $room_name(keys %{$self->{rooms}}){
>>         $self->{rooms}->{$room_name}->disconnect_jid($bj);
>>       }
>>     });
> 
> 
> DJabberd-MUC/lib/DJabberd/Plugin/MUC/Room.pm
> 17a18,22
>> sub disconnect_jid {
>>     my ($self, $jid)=@_;
>>     $self->remove($self->{jid2nick}->{lc($jid)},lc($jid));
>> }
> 
> Any opinions on which is the better approach?  I went my way because I
> figured that was why the ConnectionClosing hook was for...

Does this work when the MUC and the VHost aren't running in the same 
process? For example, does the "phantom presence" also occur if DJabberd 
has connected to it a third-party MUC component, or if the DJabberd user 
is connected to a remote MUC service? Does this also manifest as 
leftover active connections on legacy IM transports?

My gut feel is that this is really a bug in ClientIn which has the 
symptom of phantom presences in MUC rooms. Unless I'm misunderstanding 
the issue, I think your change is treating a symptom rather than the 
root cause.