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
regardless ("Fix D"), this would allow a channel to not have to rely
on a services bot (although really this should probably be a channel
mode like +o/+v)
- xplora
On 29/10/2005, at 1:40 AM, Andrew Miller wrote:
Progs wrote:
Hi,
If I have two servers, AA and AB, with AAAAA and ABAAA on #foo, a
+D channel.
AAAAA is delayed on #foo and ABAAA is +d.
There are only AAAAA and ABAAA in #foo.
When AAAAA speaks on #foo, ABAAA is +d so AB doesn't receive
message, so ABAAA doesn't see AAAAA's join.
Bug or feature ?:)
This could be used to build a map of the network and determine
where the
hubs are. Anything which breaks HIS that bad is a bug.
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 state in each server.
Finally,
if a message causes RevealDelayed, it should propagate to all servers,
not just those with non-deaf members on the channel.
Fix B: Deaf users can't join +D or +d channels, and users in +D or + d
channels can't become deaf.
Fix C: Deaf users joining a +D or +d channel force a full reveal to
everyone on that server(I think we can rule this one out)
Fix D: Deaf users joining a +D or +d channel can see everyone, and
can't
set -d usermode(to prevent seeing the same join twice, when
RevealDelayed is called) while in channel.
Fix E: Deaf users joining +D or +d channel get a full reveal, and if
they set -d, we set WASDEAF on all +D or +d channels they are in.
Users
with Deaf usermode or WASDEAF status in the channel do not see
messages
sent by RevealDelayed as they have already seen them earlier. They do
see parts for delayed users.
How many users set -d once they are connected anyway? Probably not
many,
so fix D might be reasonable. Fix A requires a server protocol
change(and costs extra bandwidth on burst). In the light of the
bandwidth problems with A and C, and the feature restrictions of B and
D, only E remains(or G, "do nothing" :) ).
Opinions?
_______________________________________________
Coder-com mailing list
Coder-com@undernet.org
http://undernet.sbg.org/mailman/listinfo/coder-com
--
CAUTION: This communication is confidential and may be legally privileged.
If you have received it in error you must not use, disclose, copy or retain
it. Please immediately notify us by return email and then delete the email.
This message has been scanned for viruses and dangerous content by
MailScanner with McAfee UVScan, and is believed to be clean.
_______________________________________________
Coder-com mailing list
Coder-com@undernet.org
http://undernet.sbg.org/mailman/listinfo/coder-com
