software/!RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2007/003287.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices Coding] Feature Suggestions
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Feature%20Suggestions&In-Reply-To=debb3bc0704160327j6d7e7bb4ta442f7960f840eaf%40mail.gmail.com">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="003286.html">
  11    <LINK REL="Next"  HREF="003288.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices Coding] Feature Suggestions</H1>
  15     <B>Andrew Church</B>
  16     <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Feature%20Suggestions&In-Reply-To=debb3bc0704160327j6d7e7bb4ta442f7960f840eaf%40mail.gmail.com"
  17        TITLE="[IRCServices Coding] Feature Suggestions">achurch at achurch.org
  18        </A><BR>
  19     <I>Tue Apr 17 15:53:22 PDT 2007</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="003286.html">[IRCServices Coding] Feature Suggestions
  22 </A></li>
  23         <LI>Next message: <A HREF="003288.html">[IRCServices Coding] Debian packages
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#3287">[ date ]</a>
  27               <a href="thread.html#3287">[ thread ]</a>
  28               <a href="subject.html#3287">[ subject ]</a>
  29               <a href="author.html#3287">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>     To the original poster: Don't use HTML mail on this list.
  35
  36 &gt;&gt;<i> 1. /ns set autoop [on|off] - Just like Anope
  37 </I>&gt;<i>
  38 </I>&gt;<i>If this is what I think it is, which is that the nick in question
  39 </I>&gt;<i>won't be auto-opped on any channel (next time please elaborate on what
  40 </I>&gt;<i>Anope does), I believe that Andrew may have been considering this at
  41 </I>&gt;<i>one point (I think it was in one of the TODO lists). That being said,
  42 </I>&gt;<i>I haven't seen this in 5.1, so it may have been dropped or thrown out.
  43 </I>
  44      I've never seen the point to this option (if you don't want auto-ops,
  45 don't have people give you auto-op access), so I won't be adding it.
  46
  47 &gt;&gt;<i> 2. I think channel passwords suck, so:
  48 </I>[...]
  49
  50      I agree, but removing them at this point is not feasible, so I've left
  51 it documented as something for future developers to think about (technical
  52 manual section 11).
  53
  54 &gt;&gt;<i> 3. /cs clear #channel users - make this only kick users who don't have the
  55 </I>&gt;&gt;<i> access to use it.
  56 </I>
  57      I'd rather keep it the way it is--kick everybody out and let the users
  58 sort things out afterwards.  (Changing it as you suggest would undoubtedly
  59 leave users wondering &quot;why didn't user X get kicked?&quot;)
  60
  61 &gt;&gt;<i> 4. When someone sets a new founder for the channel, they immediately lose
  62 </I>&gt;&gt;<i> their founder-level access.
  63 </I>
  64      This is already the case (unless the founder used the IDENTIFY command
  65 to gain privileges, in which case there would be no point in dropping
  66 privileges because he could just identify again).
  67
  68 &gt;&gt;<i> 5. /ns listchans - make this list all of the user's channel accesses, like
  69 </I>&gt;&gt;<i> /ns alist in Anope
  70 </I>&gt;<i>
  71 </I>&gt;<i>If I understand you correctly, you want this to display the access
  72 </I>&gt;<i>list for a channel as well. Services already does this. (/msg ChanServ
  73 </I>&gt;<i>ACCESS #channel LIST - or something like that)
  74 </I>
  75      I think the intention was a new command to list every channel the user
  76 has a nonzero access level on, along with that access level.  I don't see
  77 that as necessary, because (as you say) ChanServ ACCESS can already display
  78 the access level of a particular list; also, the time required to search
  79 through all access lists of all channels could be prohibitively long on
  80 large networks.
  81
  82 &gt;&gt;<i> 6. When someone does /cs info #channel, and it shows the mode lock, make it
  83 </I>&gt;&gt;<i> show the locked mode paramaters too.
  84 </I>&gt;<i>
  85 </I>&gt;<i>Bad idea. I'm sure that no-one wants to see their channel key
  86 </I>&gt;<i>displayed in this manner. :)
  87 </I>
  88      Exactly.  As for other modes, just look at the channel's current mode
  89 set, which will naturally be the same as what's set in the mode lock.
  90
  91   --Andrew Church
  92     <A HREF="http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org</A>
  93     <A HREF="http://achurch.org/">http://achurch.org/</A>
  94 </PRE>
  95
  96
  97 <!--endarticle-->
  98     <HR>
  99     <P><UL>
 100         <!--threads-->
 101         <LI>Previous message: <A HREF="003286.html">[IRCServices Coding] Feature Suggestions
 102 </A></li>
 103         <LI>Next message: <A HREF="003288.html">[IRCServices Coding] Debian packages
 104 </A></li>
 105          <LI> <B>Messages sorted by:</B>
 106               <a href="date.html#3287">[ date ]</a>
 107               <a href="thread.html#3287">[ thread ]</a>
 108               <a href="subject.html#3287">[ subject ]</a>
 109               <a href="author.html#3287">[ author ]</a>
 110          </LI>
 111        </UL>
 112
 113 </body></html>