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 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.
It's a solution for desynchronize delayed, but heavy. > 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 ? > 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) With a message sent ? > 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. bad. > 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. I don't understand. > 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
