software/!RELEASES/ircservices/achurch.org/services/lists/ircservices/2001/001627.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices] A discussion on the contents of the todo file
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20A%20discussion%20on%20the%20contents%20of%20the%20todo%20file&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="001637.html">
  11    <LINK REL="Next"  HREF="001628.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices] A discussion on the contents of the todo file</H1>
  15     <B>Bryan Clark</B>
  16     <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20A%20discussion%20on%20the%20contents%20of%20the%20todo%20file&In-Reply-To="
  17        TITLE="[IRCServices] A discussion on the contents of the todo file">bclark at bclark.yi.org
  18        </A><BR>
  19     <I>Sun Mar 18 18:00:13 PST 2001</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="001637.html">[IRCServices] A discussion on the contents of the todo file
  22 </A></li>
  23         <LI>Next message: <A HREF="001628.html">[IRCServices] A discussion on the contents of the todo file
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#1627">[ date ]</a>
  27               <a href="thread.html#1627">[ thread ]</a>
  28               <a href="subject.html#1627">[ subject ]</a>
  29               <a href="author.html#1627">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>On Sun, 18 Mar 2001 20:00:00 +0500, Imran Ali Rashid said:
  35
  36 &gt;<i> Warning: this is a LONG email.
  37 </I>
  38 Reply won't be quite as long -- don't worry. ;)
  39
  40 &gt;<i>  &gt; ** Warn about being kicked off after N password failures
  41 </I>&gt;<i>
  42 </I>&gt;<i>  Has there been a discussion on this?
  43 </I>&gt;<i>
  44 </I>
  45 I'm not sure if there was, but I don't see the point of a warning -- if
  46 all you're going to do is kill them, no user intent on cracking a
  47 password is going to care all that much.
  48
  49 &gt;<i>  &gt; OS REHASH command
  50 </I>
  51 I thought rehash was already added .........
  52
  53 &gt;<i>  &gt; CS SET REVENGE (reverses ban, etc. set by lower level user on
  54 </I>&gt;<i>  higher,
  55 </I>&gt;<i>    and optionally deops/kicks/bans lower level user)
  56 </I>
  57 Couldn't really see the point of this, either -- there was a long
  58 discussion about it about a month ago.
  59
  60 &gt;<i>  &gt; CS Last used time for access, AKICK entries
  61 </I>&gt;<i>
  62 </I>&gt;<i>  This is a good idea. This was even mentioned by someone recently.
  63 </I>&gt;<i>  So lets discuss it and see how many people like it.
  64 </I>&gt;<i>
  65 </I>
  66 As an extension to that, I was considering making those entries expire
  67 after a certain amount of time. I got it to work well enough on mine for
  68 akicks, but I just decided to scrap it for access-list entries -- I
  69 figure that access lists are normally far longer than akick lists, so
  70 it'd just slow things down too much on any medium-sized network.
  71
  72 As far as just showing the last-used time, though, I don't see any
  73 problems with that.
  74
  75 &gt;<i>  &gt; NS SET ALL (especially PASSWORD) for all linked nicks
  76 </I>&gt;<i>
  77 </I>
  78 I don't like the SET ALL idea either, mainly for the reasons you gave.
  79 Something similar to Dal's &quot;/chanserv why&quot; command, on the other hand,
  80 probably wouldn't be too hard (just an extension of the current
  81 &quot;/chanserv listchans&quot; that was being talked about a couple of days ago,
  82 really).
  83
  84 &gt;<i>  &gt; MS MemoServ IGNORE {ADD,DEL,LIST}
  85 </I>&gt;<i>
  86 </I>&gt;<i>  to help against this and cases of memo flooding, a
  87 </I>&gt;<i>  command may be put in to get rid of the memos of a
  88 </I>&gt;<i>  certain nick.
  89 </I>
  90 Or by being able to ignore a hostmask, maybe ....... it'd make things
  91 more difficult for the flooder, at least.
  92
  93 &gt;<i>  &gt; ** Add a way to send OperServ (and other?) commands from the shell
  94 </I>&gt;<i>
  95 </I>&gt;<i>  This is defintely a big help. but how about just having a telnet
  96 </I>&gt;<i>  session with services, since that would facilitate an
  97 </I>&gt;<i>  easier access to commands, and is a seemingly good idea... I'm waiting
  98 </I>&gt;<i>  for people to shoot holes through this, since I
  99 </I>&gt;<i>  haven't really thought on it a lot.
 100 </I>&gt;<i>
 101 </I>
 102 Telnetting to services ......... it'd be complicated at best, the way I'm
 103 imagining it. I know it seems like Services is a server when it connects
 104 to a network, but at its heart, it's really a client, since it's not set
 105 up to actually accept connections -- it only initiates them. Perhaps
 106 it'll be easier to do with the modularization in Services 5.0, but right
 107 now, adding the server capabilities to Services looks like it would
 108 require a bit more than a couple of new functions.
 109
 110
 111
 112
 113 </PRE>
 114
 115 <!--endarticle-->
 116     <HR>
 117     <P><UL>
 118         <!--threads-->
 119         <LI>Previous message: <A HREF="001637.html">[IRCServices] A discussion on the contents of the todo file
 120 </A></li>
 121         <LI>Next message: <A HREF="001628.html">[IRCServices] A discussion on the contents of the todo file
 122 </A></li>
 123          <LI> <B>Messages sorted by:</B>
 124               <a href="date.html#1627">[ date ]</a>
 125               <a href="thread.html#1627">[ thread ]</a>
 126               <a href="subject.html#1627">[ subject ]</a>
 127               <a href="author.html#1627">[ author ]</a>
 128          </LI>
 129        </UL>
 130
 131 </body></html>