home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / alt / irc / 4655 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  2.4 KB
  1. Path: sparky!uunet!munnari.oz.au!manuel.anu.edu.au!coombs!titus
  2. From: titus@coombs.anu.edu.au (titus chiu)
  3. Newsgroups: alt.irc
  4. Subject: Re: yes or no? (bot deopping)
  5. Date: 15 Dec 1992 01:02:11 GMT
  6. Organization: Coombs Computing Unit, Australian National University, Canberra.
  7. Lines: 38
  8. Message-ID: <1gjaqjINNi2j@manuel.anu.edu.au>
  9. References: <1g5lmrINNh0k@usenet.INS.CWRU.Edu> <85220@ut-emx.uucp> <1992Dec13.022557.11079@murdoch.acc.Virginia.EDU>
  10. NNTP-Posting-Host: 150.203.76.2
  11. X-Disclaimer: This message was written by a user on Coombs at ANU. The
  12.               opinions expressed are those of the user and not necessarily
  13.               those of the Australian National University.
  14.  
  15. gl8f@fermi.clas.Virginia.EDU (Greg Lindahl) writes:
  16. >I think that all your solution would do is result in an explosion of
  17. >number of servers, server operators, and kills.
  18.  
  19. why dont we just get rid of modes altogether :*) ... and have negative
  20. channels back :*) (without mode command to -s it i guess) .. as for
  21. kicks .. that really isnt necessary with the advance ignore command of
  22. the ircII clients nowadays.. is it?
  23.  
  24. >One way to reduce mode traffic is to not propagate redundant modes,
  25. >i.e. once Wumpus is a channel operator, "mode +o Wumpus" will be
  26. >rejected by the user's home server. This reduces the stupid multiple
  27.  
  28. that is a good idea.. indeed it has been around for a little while now
  29. of course (the idea that is) .. 
  30.  
  31. >mode problem, but introduces new consistancy problems.  So, the home
  32.  
  33. well.. i dont think it helps even if redundant modes are propogated
  34. will help if the servers are out of sync (in fact of course it doesnt
  35. help and just generates more traffic in the way of hack msgs)
  36.  
  37. >seconds? Does anyone think IRC would be less useful with a strict rate
  38. >limit on nick, topic, and join?
  39.  
  40. well... i doubt nick and topic msgs need to be issued in quick successions
  41. in any normal use.. as for join.. well.. the only problem i c if join
  42. command is subjected to flood control is for people who join a few channels
  43. in their .ircrc and it will slow them down a little..
  44.  
  45. titus
  46. (Say NO to unattended bots)
  47.  
  48. --
  49. titus chiu                                   -- email: ---------------------
  50.                                              ---- titus@coombs.anu.edu.au --
  51.   dont drink and drive home                  ---- titus@turing.ORG ---------
  52.   get stoned and fly home.                   -------------------------------
  53.