1 |
<?xml version="1.0" encoding="ISO-8859-1"?> |
2 |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd"> |
3 |
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> |
4 |
<head> |
5 |
<meta http-equiv="Content-Style-Type" content="text/css"/> |
6 |
<style type="text/css">@import "style.css";</style> |
7 |
<title>IRC Services Technical Reference Manual - 11. Future work</title> |
8 |
</head> |
9 |
|
10 |
<body> |
11 |
<h1 class="title" id="top">IRC Services Technical Reference Manual</h1> |
12 |
|
13 |
<h2 class="section-title">11. Future work</h2> |
14 |
|
15 |
<p class="section-toc"> |
16 |
11-1. <a href="#s1">Design issues</a> |
17 |
<br/>11-2. <a href="#s2">User interface issues</a> |
18 |
<br/> 11-2-1. <a href="#s2-1">NickServ issues</a> |
19 |
<br/> 11-2-2. <a href="#s2-2">ChanServ issues</a> |
20 |
<br/> 11-2-3. <a href="#s2-3">MemoServ issues</a> |
21 |
<br/> 11-2-4. <a href="#s2-4">OperServ issues</a> |
22 |
<br/> 11-2-5. <a href="#s2-5">StatServ issues</a> |
23 |
<br/> 11-2-6. <a href="#s2-6">Other issues</a> |
24 |
<br/> 11-2-7. <a href="#s2-7">Rejected suggestions</a> |
25 |
</p> |
26 |
|
27 |
<p class="backlink"><a href="10.html">Previous section: Compilation</a> | |
28 |
<a href="index.html">Table of Contents</a></p> |
29 |
|
30 |
<!------------------------------------------------------------------------> |
31 |
<hr/> |
32 |
|
33 |
<h3 class="subsection-title" id="s1">11-1. Design issues</h3> |
34 |
|
35 |
<ul> |
36 |
|
37 |
<li class="spaced">Services currently operates under the assumption that |
38 |
enough memory will be available for its needs, and simply aborts the |
39 |
program in most cases if a memory allocation fails (the <tt>smalloc()</tt> |
40 |
function). On modern systems this should be true most of the time anyway, |
41 |
but a better design would eliminate <tt>smalloc()</tt> and friends, and |
42 |
instead degrade gracefully when out of resources (for example, returning an |
43 |
"internal error" or "out of resources" message to a pseudoclient command).</li> |
44 |
|
45 |
<li class="spaced">Services ignores the possibility of truncation when |
46 |
using the <tt>snprintf()</tt> and <tt>vsnprintf()</tt> functions. In most |
47 |
cases, such truncation would only result in the user seeing a truncated |
48 |
response string, and I have (at least in recent development) made an effort |
49 |
to check for overflow in security-related situations before calling |
50 |
<tt>snprintf()</tt>, but I cannot rule out the possibility that some |
51 |
security issues related to string truncation exist. The code should be |
52 |
rewritten to (1) use an <tt>snprintf()</tt> that follows the POSIX |
53 |
standard of returning the number of bytes that would be written given an |
54 |
infinite buffer and (2) check the return value for overflow where |
55 |
pertinent.</li> |
56 |
|
57 |
<li class="spaced">As also mentioned in <a href="10.html#s5">section |
58 |
10-5</a>, the module callback implementation relies on the very flaky |
59 |
assumption that any type can be passed through a <tt>void *</tt> and |
60 |
come out unscathed on the other side, regardless of the parameter types |
61 |
used by the called function. This happens to work on the Intel x86 |
62 |
architecture because everything is 32 bits, and on the AMD x86-64 |
63 |
architecture because the first five parameters (the maximum supported for |
64 |
callbacks in the current implementation) are passed in registers rather |
65 |
than on the stack, but there is no guarantee that this will also work on |
66 |
future (or other existing) architectures. The implementation also assumes |
67 |
that a function can be passed more parameters than it actually accepts |
68 |
without any harm. One possible alternative is to use variadic argument |
69 |
lists, but this would require changing all callback functions to take a |
70 |
<tt>va_list</tt> argument and retrieve the arguments manually; due to the |
71 |
amount of work this would take, the current implementation has been left |
72 |
alone for this release, and a redesign is left for future work.</li> |
73 |
|
74 |
<li class="spaced">Services defines its own types for integers of specific |
75 |
sizes: <tt>int8</tt>, <tt>uint32</tt>, and the like. The standard header |
76 |
file <tt>stdint.h</tt> declares similar types, using names like |
77 |
<tt>int8_t</tt> and <tt>uint32_t</tt>; however, these are not used because |
78 |
this header file did not exist (or was not standardized, at least) during |
79 |
the early stages of Services' development, when the need for sized integer |
80 |
types arose. Changing the code to use the standard types would remove the |
81 |
need to define those types in the <tt>configure</tt> script.</li> |
82 |
|
83 |
<li class="spaced">It has been suggested from time to time that Services |
84 |
use a full-fledged database management system such as MySQL for database |
85 |
storage, to allow easy access to the data by other programs such as CGI |
86 |
scripts on a web server. In fact, the major services programs I am aware |
87 |
of which are currently (October 2007) under development seem to be taking |
88 |
this route. However, Services has been designed from the start with the |
89 |
assumption that its data will never be modified by any outside process, and |
90 |
in fact, even the change from periodic expiration to expiration on access |
91 |
made during 5.0 alpha development caused several dangling-pointer bugs to |
92 |
surface. Attempting to use external databases that could be modified by |
93 |
other programs within the current Services framework would at best cause |
94 |
such modified data to be overwritten when Services saved its databases, and |
95 |
at worst cause Services to crash when it tried to access data that had been |
96 |
modified without its knowledge. That said, this design decision enforces a |
97 |
single-threaded execution model for the entire program, and for that reason |
98 |
alone is a good target for redesign. (With respect to read-only access to |
99 |
Services data, XML-based data export was added in version 5.0.)</li> |
100 |
|
101 |
<li class="spaced">In relation to the above, XML has also been suggested as |
102 |
a native database format. I have been reluctant to do this, both from the |
103 |
practical point of view that writing the databases in a textual format |
104 |
takes considerably longer than doing so in a binary format and would impair |
105 |
Services' responsiveness, and because I see XML as a data interchange |
106 |
format rather than a data storage format and believe that the two should be |
107 |
handled separately. However, the former issue may well be moot for smaller |
108 |
networks, and the latter is a matter of taste; in addition, the current XML |
109 |
import and export modules lack the flexibility of the database system, as |
110 |
discussed at the top of <a href="8.html#s4-1">section 8-4-1</a>, so I leave |
111 |
this issue here for consideration.</li> |
112 |
|
113 |
<li class="spaced">Currently, Services records all log messages to a single |
114 |
log file, in a format intended for human perusal rather than machine |
115 |
processing. This could be improved with an "event log" system and logging |
116 |
modules, whereby a common log function is called with some sort of event |
117 |
identifier and event data, and the log module(s) then perform appropriate |
118 |
actions; this would allow, for example, the creation of a log file with |
119 |
all nickname-related events stored in a format easily parsable by other |
120 |
programs, or the creation of an online "log channel" to which nickname and |
121 |
channel operations are sent.</li> |
122 |
|
123 |
<li class="spaced">ChanServ currently requires a password for founder-level |
124 |
access to registered channels. However, since those privileges are also |
125 |
granted to the founder him/herself upon nickname identification, channel |
126 |
passwords could be considered optional; deliberately not setting a password |
127 |
on a channel would thus prevent the channel from being taken over by |
128 |
password theft. However, the password also serves as an extra measure to |
129 |
prevent accidental dropping of channels (the <tt>DROP</tt> command requires |
130 |
password authentication), so an alternate method would have to be |
131 |
considered if channel passwords were made optional.</li> |
132 |
|
133 |
<li class="spaced">As mentioned in <a href="7.html#s4-1-4">section |
134 |
7-4-1-4</a>, it may be desirable to include "successor" channels in a |
135 |
user's owned-channel count. This would alleviate the potential for a |
136 |
channel with a successor to nonetheless disappear on deletion of the |
137 |
founder's nickname (because the successor owned too many channels at that |
138 |
particular time).</li> |
139 |
|
140 |
<li class="spaced">Services has used a level-based access system since its |
141 |
inception, in which channel users are assigned a single numeric access |
142 |
level; this level then determines what privileges (if any) the user is |
143 |
allowed on the channel. While more flexible than a simple system like the |
144 |
XOP command set, the use of numbers can prove confusing and difficult to |
145 |
understand, and there is no way to selectively grant higher-level |
146 |
privileges without also granting lower-level ones. A system such as the |
147 |
"role" system used in PTlink Services 3.x, in which privileges are |
148 |
individually granted to users, could help solve these problems.</li> |
149 |
|
150 |
<li class="spaced">The use of binary bitfields to represent channel modes |
151 |
allows for efficient processing; however, it causes problems when changing |
152 |
from one protocol to another, because channels' mode lock data is stored |
153 |
using those same bitfields. One way around this is to simply export and |
154 |
re-import the data using XML (which is probably a good idea in any case, to |
155 |
compensate for things like different processing of nicknames and channel |
156 |
names). An alternative approach would be to store the modes as strings, at |
157 |
the cost of additional processing and storage requirements. Still another |
158 |
approach might define a common set of mode bits among all protocols, |
159 |
allowing other protocols' modes to be interpreted properly; in essence, the |
160 |
set of modes defined in the core mode handling would be the union of all |
161 |
those defined in the standard protocol modules, rather than the |
162 |
intersection. However, this would require wider data fields to handle the |
163 |
necessity of giving every mode its own unique bit, and would leave |
164 |
third-party protocol modules without a way to express their own custom |
165 |
modes. The wisdom of including protocol-specific data in the Services core |
166 |
is also questionable.</li> |
167 |
|
168 |
<li class="spaced">The OperServ privilege system is currently very coarse. |
169 |
It essentially provides only three distinct classes: no privileges, |
170 |
Services operator, and Services administrator. (The super-user class is |
171 |
identical to the administrator class except for the ability to modify the |
172 |
Services administrator list and to bypass the NSSecureAdmins security |
173 |
restrictions.) Moreover, the privileges granted to Services operators are |
174 |
very limited, while those granted to Services administrators are extremely |
175 |
powerful, leaving no "middle ground". At least one user of Services has |
176 |
noted that the inability to view user information, for example to resolve |
177 |
disputes between users, without also granting full administrator privileges |
178 |
is problematic. Services would benefit from a review of these privilege |
179 |
classes; for example, it might be wise to require super-user privileges for |
180 |
dangerous commands such as <tt>JUPE</tt> and <tt>SHUTDOWN</tt>, which would |
181 |
then allow the administrator class to be used for tasks such as viewing |
182 |
user information.</li> |
183 |
|
184 |
<li class="spaced">Related to the above, it might be useful to allow |
185 |
OperServ privileges and related commands (such as NickServ and ChanServ |
186 |
<tt>FORBID</tt> or <tt>INFO ALL</tt>) to be assigned to different classes |
187 |
based on configuration settings. For example, one network might decide to |
188 |
allow Services operators to use information retrieval commands (currently |
189 |
limited to Services administrators), while another might choose to let all |
190 |
IRC operators use the OperServ <tt>AKILL</tt> command. Note that allowing |
191 |
this sort of configuration will require dynamically-generated help messages |
192 |
(since the required privilege class may change at runtime), in addition to |
193 |
new OperServ privilege-checking functions similar to |
194 |
<tt>is_services_oper()</tt> and <tt>is_services_admin()</tt>.</li> |
195 |
|
196 |
<li class="spaced">Configuration directives have been added somewhat |
197 |
haphazardly over the course of Services' development, and could probably |
198 |
use a review and overhaul. In particular, there are several "negative |
199 |
options", including <tt>NoBouncyModes</tt>, <tt>NoSplitRecovery</tt>, and |
200 |
<tt>NoAdminPasswordCheck</tt>, which were added as negatives to avoid |
201 |
changing Services' behavior in the middle of a release series. These have |
202 |
the unintuitive effect that <i>enabling</i> the option <i>disables</i> a |
203 |
particular behavior; ideally, such options should be written as positives |
204 |
(<i>e.g.,</i> <tt>BouncyModeCheck</tt> or <tt>SplitRecovery</tt>) and |
205 |
enabled in the default configuration file.</li> |
206 |
|
207 |
<li class="spaced" id="s1-gmake">As described in |
208 |
<a href="10.html#s3-2">section 10-3-2</a>, the module compilation process |
209 |
makes use of several time-consuming tricks to simplify the individual |
210 |
modules' Makefiles. However, version 3.81 of GNU <tt>make</tt> introduced |
211 |
the special target <tt>.SECONDEXPANSION</tt>, which causes dependency lists |
212 |
in subsequent rules to be expanded twice; for example, a rule |
213 |
<div class="code">%.so: %.o $$(OBJECTS-$$@)</div> |
214 |
(note the escaped <tt>$</tt> characters, to prevent expansion on the first |
215 |
pass) would do what it looks like—supply a dependency list using a |
216 |
variable name derived from the target module name. Use of this feature |
217 |
could substantially simplify the <tt>modules/Makerules</tt> file, at the |
218 |
expense of incompatibility with versions 3.79 and 3.80 of GNU |
219 |
<tt>make</tt>.</li> |
220 |
|
221 |
</ul> |
222 |
|
223 |
<p>There are also several issues listed in <a href="../d.html">Appendix |
224 |
D</a> of the user's manual.</p> |
225 |
|
226 |
<p class="backlink"><a href="#top">Back to top</a></p> |
227 |
|
228 |
<!------------------------------------------------------------------------> |
229 |
<hr/> |
230 |
|
231 |
<h3 class="subsection-title" id="s2">11-2. User interface issues</h3> |
232 |
|
233 |
<p>A number of possible functionality additions or changes have been |
234 |
considered by the author or suggested by users over the years. These are |
235 |
summarized by subsystem below, in no particular order.</p> |
236 |
|
237 |
<p class="backlink"><a href="#top">Back to top</a></p> |
238 |
|
239 |
|
240 |
<h4 class="subsubsection-title" id="s2-1">11-2-1. NickServ issues</h4> |
241 |
|
242 |
<ul> |
243 |
<li class="spaced">Allow certain nicknames (specified by wildcard mask) |
244 |
to be used but not registered. <i>Suggested by Mark Hetherington |
245 |
<tt><mark@ctcp.net></tt></i></li> |
246 |
<li class="spaced">Include successor channels in the output of the |
247 |
<tt>LISTCHANS</tt> command. <i>Suggested by Marc-Andre A. Fuentes |
248 |
<tt><nothing@psychopat.org></tt></i></li> |
249 |
<li class="spaced">When using the <tt>nickserv/mail-auth</tt> module, |
250 |
perform a DNS (MX) lookup on the domain in the E-mail address given |
251 |
to the <tt>REGISTER</tt> or <tt>SET EMAIL</tt> address before |
252 |
actually trying to send the authentication code message. |
253 |
<i>Suggested by Brian <tt><n1uro@n1uro.com></tt></i></li> |
254 |
<li class="spaced">Include Services administrator or operator status in |
255 |
the output from the <tt>INFO</tt> command. <i>Suggested by Yusuf |
256 |
Iskenderoglu <tt><uhc0@stud.uni-karlsruhe.de></tt></i></li> |
257 |
<li class="spaced">When the <tt>NSForceNickChange</tt> configuration option |
258 |
is set, have the <tt>GHOST</tt> command change target users' nicks |
259 |
rather than killing them outright. <i>Suggested by Mark |
260 |
Hetherington <tt><mark@ctcp.net></tt></i></li> |
261 |
<li class="spaced">An option to warn users via E-mail when a nickname is |
262 |
about to expire. <i>Suggested by Hans v Steenbergen |
263 |
<tt><thebeast@xs4all.nl></tt></i></li> |
264 |
<li class="spaced">An option to allow users to change their "fake usermask" |
265 |
(username and hostname shown in <tt>/whois</tt> output) to their |
266 |
registered E-mail address, on servers supporting such a feature.</li> |
267 |
<li class="spaced">Allow Services administrators to modify other nicknames' |
268 |
access lists. <i>Suggested by Mauritz Antunes |
269 |
<tt><mauritz@brasnet.org></tt></i></li> |
270 |
<li class="spaced">An option to limit the set of languages users are |
271 |
allowed to select with <tt>SET LANGUAGE</tt>. <i>Suggested by |
272 |
Mauritz Antunes <tt><mauritz@brasnet.org></tt></i></li> |
273 |
</ul> |
274 |
|
275 |
<p class="backlink"><a href="#top">Back to top</a></p> |
276 |
|
277 |
|
278 |
<h4 class="subsubsection-title" id="s2-2">11-2-2. ChanServ issues</h4> |
279 |
|
280 |
<ul> |
281 |
<li class="spaced">Better integration of channel keys with ChanServ; for |
282 |
example, authorized users should have a way to enter even if a |
283 |
channel key is set, much like they can use the <tt>UNBAN</tt> or |
284 |
<tt>INVITE</tt> commands to get around channel bans or mode |
285 |
<tt>+i</tt>.</li> |
286 |
<li class="spaced">An option to autokill users entering a forbidden |
287 |
channel (<i>e.g.,</i> to efficiently remove botnets from a |
288 |
network).</li> |
289 |
<li class="spaced">Allow autokick exceptions. <i>Suggested by Dionisios |
290 |
K. <tt><admin@vonitsanet.gr></tt></i></li> |
291 |
<li class="spaced">A configuration option listing channel modes that uers |
292 |
are not allowed to change, like a mode lock enforced on all |
293 |
channels. <i>Suggested by <tt><medice@gmx.at></tt></i></li> |
294 |
<li class="spaced">A ChanServ <tt>LINK</tt> command, like the NickServ |
295 |
command of the same name but for channels. <i>Suggested by Craig |
296 |
McLure <tt><Craig@chatspike.net></tt></i></li> |
297 |
<li class="spaced">A <tt>VERBOSE</tt> option, causing ChanServ to send |
298 |
notices (like for <tt>OPNOTICE</tt>) to the channel for all |
299 |
ChanServ commands. <i>Suggested by |
300 |
<tt><martin@e-tech.us></tt></i></li> |
301 |
<li class="spaced">A command to look up channels by E-mail address. |
302 |
<i>Suggested by Finny Merrill <tt><griever@t2n.org></tt></i></li> |
303 |
<li class="spaced">More intelligent handling of a missing "<tt>#</tt>" in |
304 |
the channel name parameter for <tt>REGISTER</tt>. <i>Suggested by |
305 |
<tt><jollino@sogno.net></tt></i></li> |
306 |
<li class="spaced">A better method of determining a channel's "last-used" |
307 |
time than the last time a user was auto-opped (but avoiding overly |
308 |
sensitive schemes that update the last-used time even for |
309 |
spambots).</li> |
310 |
<li class="spaced">An option to send an explanatory notice to a user who |
311 |
tries to use a restricted ChanServ command on a channel with the |
312 |
<tt>SECURE</tt> option set, without identifying for their |
313 |
nickname.</li> |
314 |
<li class="spaced">Record the nickname of the user that added each access |
315 |
entry and the last time the access entry was used.</li> |
316 |
<li class="spaced">Display access entries ordered by level.</li> |
317 |
<li class="spaced">Allow modification of (adding modes from or removing |
318 |
modes to) channel mode locks, rather than wholesale replacement |
319 |
only.</li> |
320 |
<li class="spaced">When switching IRC server types that do not share the |
321 |
same set of channel modes, graceful degradation of locked modes not |
322 |
available with the new protocol. <i>Suggested by Yusuf |
323 |
Iskenderoglu <tt><uhc0@stud.uni-karlsruhe.de></tt></i></li> |
324 |
<li class="spaced">Treat the <tt>/topic</tt> IRC command identically to the |
325 |
ChanServ <tt>TOPIC</tt> command when determining whether to allow a |
326 |
topic change on a channel with <tt>TOPICLOCK</tt> set. <i>Suggested |
327 |
by Casey <tt><caseyclaydon@fastmail.com.au></tt></i></li> |
328 |
</ul> |
329 |
|
330 |
<p class="backlink"><a href="#top">Back to top</a></p> |
331 |
|
332 |
|
333 |
<h4 class="subsubsection-title" id="s2-3">11-2-3. MemoServ issues</h4> |
334 |
|
335 |
<ul> |
336 |
<li class="spaced">A setting to reverse the meaning of the ignore list, so |
337 |
that only users on the list are allowed to send memos.</li> |
338 |
</ul> |
339 |
|
340 |
<p class="backlink"><a href="#top">Back to top</a></p> |
341 |
|
342 |
|
343 |
<h4 class="subsubsection-title" id="s2-4">11-2-4. OperServ issues</h4> |
344 |
|
345 |
<ul> |
346 |
<li class="spaced">A command to kill nicknames matching a wildcard or |
347 |
regular expression. <i>Suggested by Guy Antony Halse |
348 |
<tt><guy@rucus.ru.ac.za></tt></i></li> |
349 |
<li class="spaced">An option to send a notice to autokilled users of the |
350 |
autokill expiration time before performing the actual kill. |
351 |
<i>Suggested by <tt><saturn@jetirc.net></tt></i></li> |
352 |
<li class="spaced">The ability to use full regular expressions, not just |
353 |
simple wildcards, in autokill and other wildcard masks. |
354 |
<i>Suggested by Aragon Gouveia |
355 |
<tt><aragon@phat.za.net></tt></i></li> |
356 |
</ul> |
357 |
|
358 |
<p class="backlink"><a href="#top">Back to top</a></p> |
359 |
|
360 |
|
361 |
<h4 class="subsubsection-title" id="s2-5">11-2-5. StatServ issues</h4> |
362 |
|
363 |
<ul> |
364 |
<li class="spaced">Keep track of the number of users per domain on each |
365 |
server. <i>Suggested by Ali Sor |
366 |
<tt><alisor@softhome.net></tt></i></li> |
367 |
<li class="spaced">Keep track of statistics such as the number of joins |
368 |
and kicks for each channel and the number of connections made by |
369 |
each user or nickname. <i>Suggested by |
370 |
<tt><Georges@Berscheid.lu></tt></i></li> |
371 |
</ul> |
372 |
|
373 |
<p class="backlink"><a href="#top">Back to top</a></p> |
374 |
|
375 |
|
376 |
<h4 class="subsubsection-title" id="s2-6">11-2-6. Other issues</h4> |
377 |
|
378 |
<ul> |
379 |
<li class="spaced">An option or module to log all <tt>WALLOPS</tt> (and |
380 |
<tt>GLOBOPS</tt>, etc.) messages. <i>Suggested by Andrew |
381 |
Kempe.</i></li> |
382 |
<li class="spaced">An in-program method to clear one or more databases |
383 |
(currently, this can only be done by removing the corresponding |
384 |
database files). <i>Suggested by |
385 |
<tt><RealCFC@chatfirst.com></tt></i></li> |
386 |
<li class="spaced">A network status page, possibly with graphs (see for example |
387 |
<a href="http://irc.netsplit.de/"><tt>irc.netsplit.de</tt></a>). |
388 |
<i>Suggested by <tt><jollino@sogno.net></tt></i></li> |
389 |
<li class="spaced">An option to autokill users who are killed repeatedly |
390 |
for bad passwords. <i>Suggested by Jonathan Morton |
391 |
<tt><chromi@cyberspace.org></tt></i></li> |
392 |
<li class="spaced">The ability to reconnect to the uplink server if |
393 |
disconnected.</li> |
394 |
<li class="spaced">A way to send commands to OperServ (or possibly other |
395 |
pseudoclients) from another process.</li> |
396 |
</ul> |
397 |
|
398 |
<p class="backlink"><a href="#top">Back to top</a></p> |
399 |
|
400 |
|
401 |
<h4 class="subsubsection-title" id="s2-7">11-2-7. Rejected suggestions</h4> |
402 |
|
403 |
<p>In addition to the above, the author has explicitly rejected a few |
404 |
feature suggestions as unnecessary or inappropriate for inclusion in |
405 |
Services; however, they are recorded here for the consideration of future |
406 |
developers.</p> |
407 |
|
408 |
<ul> |
409 |
<li class="spaced"><b>Automatic opping/voicing/etc. of users on channel |
410 |
access list changes.</b> For example, automatically setting |
411 |
<tt>+o</tt> on a user added to the access list with auto-op |
412 |
privileges. While this is certainly not a useless feature, access |
413 |
list changes are typically one-time events, and do not warrant the |
414 |
added complexity of including such a feature; the user can be |
415 |
manually opped or voiced just as easily.</li> |
416 |
<li class="spaced"><b>Allow identification to multiple nicknames.</b> |
417 |
This can result in ambiguities when handling channel access levels. |
418 |
For example, suppose a user has identified to two nicknames, |
419 |
GoodNick and BadNick. If on a certain channel, GoodNick has an |
420 |
access level of 50 but BadNick has an access level of -10, what |
421 |
access level should the user be granted? The answer varies with |
422 |
the particular channel and user, and rather than attempting to |
423 |
invent a system of options and rules to handle every possible |
424 |
circumstance, Services simply disallows identification to multiple |
425 |
nicknames entirely. (Services will remember whether a user has |
426 |
identified for a nickname if the user temporarily switches to |
427 |
another nickname.)</li> |
428 |
<li class="spaced"><b>A channel option or configuration file setting to |
429 |
make ChanServ join channels, or a BotServ pseudoclient to do the |
430 |
same thing.</b> This is one of the most common feature requests, |
431 |
but it has consistently been rejected as incompatible with the |
432 |
design of Services as a streamlined network tool rather than a |
433 |
users' toy, and also because standard bots can provide equivalent |
434 |
functionality much more flexibly than a single Services |
435 |
pseudoclient could.</li> |
436 |
</ul> |
437 |
|
438 |
<p class="backlink"><a href="#top">Back to top</a></p> |
439 |
|
440 |
<!------------------------------------------------------------------------> |
441 |
<hr/> |
442 |
|
443 |
<p class="backlink"><a href="10.html">Previous section: Compilation</a> | |
444 |
<a href="index.html">Table of Contents</a></p> |
445 |
|
446 |
</body> |
447 |
</html> |