]> jfr.im git - irc.git/blob - software/!RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2002/000286.html
RELEASE -> !RELEASE
[irc.git] / software / !RELEASES / ircservices / achurch.org / services / lists / ircservices-coding / 2002 / 000286.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
2 <HTML>
3 <HEAD>
4 <TITLE> [IRCServices Coding] More bugs and suggestions for Version 5.0
5 </TITLE>
6 <LINK REL="Index" HREF="index.html" >
7 <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20More%20bugs%20and%20suggestions%20for%20Version%205.0&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="000285.html">
11 <LINK REL="Next" HREF="000287.html">
12 </HEAD>
13 <BODY BGCOLOR="#ffffff">
14 <H1>[IRCServices Coding] More bugs and suggestions for Version 5.0</H1>
15 <B>Andrew Church</B>
16 <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20More%20bugs%20and%20suggestions%20for%20Version%205.0&In-Reply-To="
17 TITLE="[IRCServices Coding] More bugs and suggestions for Version 5.0">achurch at achurch.org
18 </A><BR>
19 <I>Fri Feb 15 23:56:52 PST 2002</I>
20 <P><UL>
21 <LI>Previous message: <A HREF="000285.html">[IRCServices Coding] More bugs and suggestions for Version 5.0
22 </A></li>
23 <LI>Next message: <A HREF="000287.html">[IRCServices Coding] More bugs and suggestions for Version 5.0
24 </A></li>
25 <LI> <B>Messages sorted by:</B>
26 <a href="date.html#286">[ date ]</a>
27 <a href="thread.html#286">[ thread ]</a>
28 <a href="subject.html#286">[ subject ]</a>
29 <a href="author.html#286">[ author ]</a>
30 </LI>
31 </UL>
32 <HR>
33 <!--beginarticle-->
34 <PRE>1) Will consider.
35 2) It's been there for ages, where have you been?
36 3) Fixed (this is a bug in DROPNICK preventing dropping forbidden nicks and
37 has nothing to do with #).
38 4) I thought this was in the TODO list but it looks like not; added.
39 5) No; I don't see that this is something Services needs to do.
40 6) No; it ought to be common enough knowledge that channel names begin with #.
41 7) No; see above.
42 8) If the suspension doesn't expire then the channel won't either. I do
43 agree the text is a bit misleading.
44 9) No; unnecessary complexity.
45 10) No; unnecessary complexity (as mentioned in the previous mail).
46
47 --Andrew Church
48 <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org</A>
49 <A HREF="http://achurch.org/">http://achurch.org/</A>
50
51 &gt;<i>1) Suggestion: httpd module - nickname and channel lists - add an indicator
52 </I>&gt;<i>for noexpire, forbidden, suspended etc to the lists in a similar way to the
53 </I>&gt;<i>in IRC list command.
54 </I>&gt;<i>
55 </I>&gt;<i>2) Suggestion: /cs list and /ns list - add option to list suspended
56 </I>&gt;<i>nicknames and channels to bring in line with the forbidden and noexpire
57 </I>&gt;<i>options currently available.
58 </I>&gt;<i>
59 </I>&gt;<i>3) Bug: Services allows some commands to operate on #nickname. It is
60 </I>&gt;<i>possible for example to forbid #nickname.
61 </I>&gt;<i>/ns forbid #nickname
62 </I>&gt;<i>-NickServ- Nick #nickname is now forbidden.
63 </I>&gt;<i>/ns dropnick #nickname
64 </I>&gt;<i>-NickServ- Internal error--unable to process request.
65 </I>&gt;<i>/ns info will operate on an invlaid nick e.g.
66 </I>&gt;<i>Nick #nick isn't registered.
67 </I>&gt;<i>Where commands are used including a # character, or indeed any unsupported
68 </I>&gt;<i>character, the response might be better as:
69 </I>&gt;<i>-NickServ- Nick invalidnickname may not be registered or used.
70 </I>&gt;<i>or
71 </I>&gt;<i>-NickServ- Nick invalidnickname contains invalid characters. then supply
72 </I>&gt;<i>list of valid characters
73 </I>&gt;<i>Services should explicitly not support # in all nickserv commands to avoid
74 </I>&gt;<i>confusion.
75 </I>&gt;<i>Finally, maybe services could also do a similar thing to the '#' channel on
76 </I>&gt;<i>startup to clear out these nicks that are now stuck in my database :)
77 </I>&gt;<i>
78 </I>&gt;<i>4) Suggestion: /cs forbid and /ns forbid - introduce reason field for
79 </I>&gt;<i>forbid in a similar manner to the suspend command.
80 </I>&gt;<i>
81 </I>&gt;<i>5) Suggestion: Services admin /cs drop and /ns dropnick - Add a reason
82 </I>&gt;<i>field which is broadcast through globops and logged along with the drop
83 </I>&gt;<i>command. Useful for working out later why a channel or nickname was
84 </I>&gt;<i>dropped.
85 </I>&gt;<i>
86 </I>&gt;<i>6) Text bug: '/cs drop channel' produces:
87 </I>&gt;<i>-ChanServ- Syntax: FORBID channel
88 </I>&gt;<i>-ChanServ- Type /msg ChanServ HELP FORBID for more information.
89 </I>&gt;<i>Suggest that it be changed to &quot;FORBID #channel&quot;, and/or additional
90 </I>&gt;<i>information explaining that a # prefix is required for channel names.
91 </I>&gt;<i>
92 </I>&gt;<i>7) Text bug related to 6 - /cs drop channel produces:
93 </I>&gt;<i>-ChanServ- Channel channel isn't registered.
94 </I>&gt;<i>which although correct, to be consistent with the requirement of the prefix
95 </I>&gt;<i># ought to produce a failure message and the suggested additional
96 </I>&gt;<i>information about the prefix listed in 6.
97 </I>&gt;<i>
98 </I>&gt;<i>8) Bug - either in text or operation - /cs help suspend produces the
99 </I>&gt;<i>following information:
100 </I>&gt;<i>-ChanServ- Unlike a forbidden channel, a suspended one does not
101 </I>&gt;<i>-ChanServ- lose its information and will expire!
102 </I>&gt;<i>However, such channels do not seem to expire. As an example, a channel that
103 </I>&gt;<i>was registered and suspended in November 2001 still remains suspended
104 </I>&gt;<i>today.
105 </I>&gt;<i>-ChanServ- Registered: Nov 22 10:11:24 2001 GMT
106 </I>&gt;<i>-ChanServ- Last used: Nov 22 23:53:18 2001 GMT
107 </I>&gt;<i>-ChanServ- Channel #modshack is suspended and may not be used or identified
108 </I>&gt;<i>for.
109 </I>&gt;<i>If the help text means that they would expire if unsuspended, then the text
110 </I>&gt;<i>ought to be changed to reflect this. The problem appears to be in the
111 </I>&gt;<i>version 4.5.x series as well as version 5 since the channels I have noticed
112 </I>&gt;<i>it on were originally suspended under a version of 4.5.x and remained
113 </I>&gt;<i>unexpired after migrating to 5.0.
114 </I>&gt;<i>
115 </I>&gt;<i>9) Suggested config option to limit guest nick length. The new guest nicks
116 </I>&gt;<i>can end up using a full 9 digit precision depending on IRCd limits which on
117 </I>&gt;<i>smaller networks makes them seem a little excessive. It would be nice if
118 </I>&gt;<i>there was a configuration ption to limit this. Obviously such option would
119 </I>&gt;<i>have to be accompanied by information on the minimum length requirement.
120 </I>&gt;<i>
121 </I>&gt;<i>10) Suggestion wrt IDENTIFY command: Although generally I have not found
122 </I>&gt;<i>any reasons to consider or suggest aliases for existing services commands
123 </I>&gt;<i>since they can generally be scripted client side and merely add confusion
124 </I>&gt;<i>to the command list, I have found one &quot;alias&quot; that I do implement within
125 </I>&gt;<i>our services which might prove useful to everyone. That is the addition of
126 </I>&gt;<i>the command 'ID' to perform the job of 'IDENTIFY' with nickserv and
127 </I>&gt;<i>chanserv.
128 </I>&gt;<i>The main benefit I have found is since this is a command which the majority
129 </I>&gt;<i>of users will use every time they log on, is that people coming from other
130 </I>&gt;<i>networks and services packages have the option of both so can quite easily
131 </I>&gt;<i>use this primary services command in the form they already know to identify
132 </I>&gt;<i>without having to rescript. It has helped groups of people move from other
133 </I>&gt;<i>networks very easily and I find once their basics are shown to just work,
134 </I>&gt;<i>they do not mind so much if commands for say access list management are
135 </I>&gt;<i>different. The xOP module has also been very helpful for such groups.
136 </I>&gt;<i>There is also an advantage of being simple to provide appropriate help text
137 </I>&gt;<i>for since it will not affect current translations.
138 </I>&gt;<i>The other maybe less obvious benefit is less typing for people like myself
139 </I>&gt;<i>that avoid scripts and automatic identification. :)
140 </I>&gt;<i>
141 </I>&gt;<i>
142 </I>&gt;<i>Well I think that's it ... for today at least :)
143 </I>&gt;<i>
144 </I>&gt;<i>--
145 </I>&gt;<i>Mark.
146 </I>&gt;<i>
147 </I>&gt;<i>
148 </I>&gt;<i>------------------------------------------------------------------
149 </I>&gt;<i>To unsubscribe or change your subscription options, visit:
150 </I>&gt;<i><A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding</A>
151 </I>
152 </PRE>
153
154 <!--endarticle-->
155 <HR>
156 <P><UL>
157 <!--threads-->
158 <LI>Previous message: <A HREF="000285.html">[IRCServices Coding] More bugs and suggestions for Version 5.0
159 </A></li>
160 <LI>Next message: <A HREF="000287.html">[IRCServices Coding] More bugs and suggestions for Version 5.0
161 </A></li>
162 <LI> <B>Messages sorted by:</B>
163 <a href="date.html#286">[ date ]</a>
164 <a href="thread.html#286">[ thread ]</a>
165 <a href="subject.html#286">[ subject ]</a>
166 <a href="author.html#286">[ author ]</a>
167 </LI>
168 </UL>
169
170 </body></html>