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 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 ? > > > Services usually sit on their own server, so they probably don't have to worry. However, I agree that some bots might like to be +d on a +D channel.
>>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 ? > > This is a "flood everyone because of one +d" solution. That is obviously not good, which is why I said we can rule it 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. >> >> > >bad. > > Well, I suppose you get people telling newbies "/mode +d myname makes you an operator", in which case they would like to be able to do -d easily, but aside from that, I see little need for setting -d. > > >>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. > > See my patch. This is like D but you can set -d and you still get to see everyone until you leave the channel. > > >>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 > > > _______________________________________________ Coder-com mailing list Coder-com@undernet.org http://undernet.sbg.org/mailman/listinfo/coder-com
