software/RELEASES/ircservices/achurch.org/services/lists/ircservices/2004/004290.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices] IdleServ, channel keys, and more
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20IdleServ%2C%20channel%20keys%2C%20and%20more&In-Reply-To=">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="004294.html">
  11    <LINK REL="Next"  HREF="004295.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices] IdleServ, channel keys, and more</H1>
  15     <B>Andrew Church</B>
  16     <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20IdleServ%2C%20channel%20keys%2C%20and%20more&In-Reply-To="
  17        TITLE="[IRCServices] IdleServ, channel keys, and more">achurch at achurch.org
  18        </A><BR>
  19     <I>Tue Apr 27 09:38:44 PDT 2004</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="004294.html">[IRCServices] Creating passworded channels withChanServ enforcing.
  22 </A></li>
  23         <LI>Next message: <A HREF="004295.html">[IRCServices] Nick change
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#4290">[ date ]</a>
  27               <a href="thread.html#4290">[ thread ]</a>
  28               <a href="subject.html#4290">[ subject ]</a>
  29               <a href="author.html#4290">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>Summing up a few issues:
  35
  36 &gt;<i>Quite honestly I've been watching this argument fly around the mailing list
  37 </I>&gt;<i>for so long now that I personally am sick of it.
  38 </I>&gt;<i>
  39 </I>&gt;<i>Andy, I know you think you have valid reasons for not implementing this
  40 </I>&gt;<i>choice, but even I, with my limited intelligence can see that you're
  41 </I>&gt;<i>flogging a dead horse. Why not give people what they want?
  42 </I>
  43      Because I don't want to.  As others have correctly pointed out,
  44 Services is something I do in my spare time because I enjoy it; while I'm
  45 not one to upset people out of spite, neither do I intend to use my
  46 personal time on things I don't like.  I'm sure the people who want an
  47 IdleServ or similar feature have, to their minds, excellent reasons for it.
  48 However, none of those reasons has convinced _me_ of its usefulness, and
  49 I am also not interested in writing it for its own sake; therefore, my
  50 answer is &quot;no&quot;.  It's that simple.
  51
  52      Or did you want to hire me to write it?  If you pay, I'll write
  53 IdleServ and anything else you want.
  54
  55 &gt;<i>It can't slow down Services too greatly as a server such as GamSurge
  56 </I>&gt;<i>A.K.A. GamesNet who uses SRVX has ChanServ in their 30,000+ Channels with
  57 </I>&gt;<i>obviously more users than that. They seem to respond perfectly fine 90-95%
  58 </I>&gt;<i>of the time. Perhaps SRVX has developed a good method? They mustn't ignore
  59 </I>&gt;<i>channel text as srvx has channel triggers?
  60 </I>
  61      One, 90-95% isn't good enough for me.  Two, they probably have a
  62 high-powered server for running Services, but not everyone has such a
  63 server--my own homepage, for example, is served off a 166MHz Pentium, and
  64 the network I originally developed Services for used a 486 for both
  65 Services and the ircd.
  66
  67 &gt;<i>Hello.. I think this is a solution... services must
  68 </I>&gt;<i>check if the user know the channel key. So if someone
  69 </I>&gt;<i>is the *first* user who wants to join a channel with
  70 </I>&gt;<i>mlock +k he must type a command first like this: /cs
  71 </I>&gt;<i>keyjoin #chan channel key ... If someone try to join a
  72 </I>&gt;<i>channel without typing this command ChanServ will
  73 </I>&gt;<i>kick and ban him..
  74 </I>
  75      This is an interesting thought, but the same thing should be able to
  76 be accomplished with ChanServ access lists and SET RESTRICTED.
  77
  78 &gt;<i>1) I think its not right to ignore an email even if
  79 </I>&gt;<i>the answer exists on the search box:-p
  80 </I>
  81      In general, I don't ignore messages just out of spite.  I do tend to
  82 ignore them if (1) the answer is in the FAQ, (2) the sender refuses to
  83 listen to what I've already said, or (3) the message isn't readable at all,
  84 e.g. HTML or multipart mail (Craig McLure, check your mailreader settings--
  85 some of your messages are going out as multipart base64, which my
  86 mailreader doesn't grok).  Again, for something I'm doing on my free time,
  87 I think that's perfectly reasonable.
  88
  89   --Andrew Church
  90     <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at achurch.org</A>
  91     <A HREF="http://achurch.org/">http://achurch.org/</A>
  92
  93
  94 </PRE>
  95
  96 <!--endarticle-->
  97     <HR>
  98     <P><UL>
  99         <!--threads-->
 100         <LI>Previous message: <A HREF="004294.html">[IRCServices] Creating passworded channels withChanServ enforcing.
 101 </A></li>
 102         <LI>Next message: <A HREF="004295.html">[IRCServices] Nick change
 103 </A></li>
 104          <LI> <B>Messages sorted by:</B>
 105               <a href="date.html#4290">[ date ]</a>
 106               <a href="thread.html#4290">[ thread ]</a>
 107               <a href="subject.html#4290">[ subject ]</a>
 108               <a href="author.html#4290">[ author ]</a>
 109          </LI>
 110        </UL>
 111
 112 </body></html>