you missed one...
how about processing the channels +D/+d state on a channel message
before processing a users Deaf mode status? after all, it only needs
to do this to decide if it needs to send a join to a Deaf user.
personally I like the idea that a Deaf user would see all joins
regardl
On Friday 28 October 2005 14:40, Andrew Miller wrote:
> Progs wrote:
> >If I have two servers, AA and AB, with A and ABAAA on #foo, a +D
> > channel. A is delayed on #foo and ABAAA is +d.
> >There are only A and ABAAA in #foo.
> >When A speaks on #foo, ABAAA is +d so AB doesn't rece
Original Message
> On Sat, 29 Oct 2005 01:40:56 +1300
> Andrew Miller <[EMAIL PROTECTED]> wrote:
> > Fix B: Deaf users can't join +D or +d channels, and users in +D or + d
> > channels can't become deaf.
>
> It's a bad solution. What about services ?
>
+d-k users should not
Progs wrote:
>On Sat, 29 Oct 2005 01:40:56 +1300
>Andrew Miller <[EMAIL PROTECTED]> wrote:
>
>
>>There are several fixes:
>>Fix A: We need to globally synchronise delayed state, which means that
>>we need to transmit it in BURST. We can then apply the "don't propagate
>>WASDELAYED" because we ca
Andrew Miller wrote:
>Progs wrote:
>
>
>
>>Hi,
>>
>>If I have two servers, AA and AB, with A and ABAAA on #foo, a +D channel.
>>A is delayed on #foo and ABAAA is +d.
>>There are only A and ABAAA in #foo.
>>When A speaks on #foo, ABAAA is +d so AB doesn't receive message, so
>>AB
On Sat, 29 Oct 2005 01:40:56 +1300
Andrew Miller <[EMAIL PROTECTED]> wrote:
>
> There are several fixes:
> Fix A: We need to globally synchronise delayed state, which means that
> we need to transmit it in BURST. We can then apply the "don't propagate
> WASDELAYED" because we can track delayed sta
Progs wrote:
>Hi,
>
>If I have two servers, AA and AB, with A and ABAAA on #foo, a +D channel.
>A is delayed on #foo and ABAAA is +d.
>There are only A and ABAAA in #foo.
>When A speaks on #foo, ABAAA is +d so AB doesn't receive message, so ABAAA
>doesn't see A's join.
>
>Bug
