]>
Commit | Line | Data |
---|---|---|
3bd189cb JR |
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> |
2 | <HTML> | |
3 | <HEAD> | |
4 | <TITLE> [IRCServices] ACCESS and *OP | |
5 | </TITLE> | |
6 | <LINK REL="Index" HREF="index.html" > | |
7 | <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20ACCESS%20and%20%2AOP&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="000531.html"> | |
11 | <LINK REL="Next" HREF="000534.html"> | |
12 | </HEAD> | |
13 | <BODY BGCOLOR="#ffffff"> | |
14 | <H1>[IRCServices] ACCESS and *OP</H1> | |
15 | <B>Andrew Church</B> | |
16 | <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20ACCESS%20and%20%2AOP&In-Reply-To=" | |
17 | TITLE="[IRCServices] ACCESS and *OP">achurch at dragonfire.net | |
18 | </A><BR> | |
19 | <I>Sat May 13 01:37:19 PDT 2000</I> | |
20 | <P><UL> | |
21 | <LI>Previous message: <A HREF="000531.html">[IRCServices] IRC Services (fwd) | |
22 | </A></li> | |
23 | <LI>Next message: <A HREF="000534.html">[IRCServices] ACCESS and *OP | |
24 | </A></li> | |
25 | <LI> <B>Messages sorted by:</B> | |
26 | <a href="date.html#533">[ date ]</a> | |
27 | <a href="thread.html#533">[ thread ]</a> | |
28 | <a href="subject.html#533">[ subject ]</a> | |
29 | <a href="author.html#533">[ author ]</a> | |
30 | </LI> | |
31 | </UL> | |
32 | <HR> | |
33 | <!--beginarticle--> | |
34 | <PRE>><i>How would everyone fell if we removed the ACCESS command and replaced it | |
35 | </I>><i>with AOP SOP etc? This would simplify things dramatically and I know it | |
36 | </I>><i>would affect those people who want very customisable channel access | |
37 | </I>><i>levels. | |
38 | </I> | |
39 | This is a bit late because I haven't had Internet access for the past | |
40 | two weeks (just moved to a new apartment), but here's my two cents on the | |
41 | subject. | |
42 | ||
43 | Without touching (yet) the subject of A/S/VOP, I'm very strongly | |
44 | against the removal of the ACCESS command. While I have to admit part of | |
45 | that is the fact that I created that system and happen to like it, there | |
46 | are a couple of other big problems that would crop up: | |
47 | ||
48 | 1) You don't just remove a feature without warning or everyone who's | |
49 | been using that feature gets screwed. Some people on the mailing list | |
50 | have already mentioned it, but there are people who are perfectly used to | |
51 | the current ACCESS command and in fact don't even know about AOP/SOP/etc. | |
52 | ||
53 | 2) Converting current channel databases to work without ACCESS would | |
54 | be a nightmare, and even in the best scenario some settings would be lost. | |
55 | Do you want to tell a user "we upgraded our software and now you can't do | |
56 | this anymore"? | |
57 | ||
58 | As for the addition of AOP/SOP/etc commands, I am not overly against | |
59 | them except inasmuch as they represent a "standard" that doesn't have to | |
60 | be a standard; I also remember quite well the numerous complaints that | |
61 | people found the level system difficult to use. On the other hand, I have | |
62 | come to detest the attitude of Microsoft (among others) to do their best | |
63 | to keep you ignorant even if you know what you're doing, and taking out | |
64 | the ACCESS command would be too close to that for my liking. What I would | |
65 | recommend is to add the *OP functions, either as commands or as | |
66 | alternatives for the ACCESS ADD level value, and have those functions in | |
67 | turn call ACCESS ADD with an appropriate level. Naturally, this would not | |
68 | work if the channel levels had been changed, but by adding an EXPERT | |
69 | channel option as someone else suggested and disallowing level changes | |
70 | without EXPERT set, AOP/SOP/etc become workable again under the ACCESS | |
71 | system. | |
72 | ||
73 | My personal preference is to use *OP as an option to the ACCESS ADD | |
74 | command, and display levels by name in LIST if EXPERT is not set. The | |
75 | user/Services dialogue would look something like this: | |
76 | ||
77 | -> *ChanServ* access #channel add SomeNick sop | |
78 | -ChanServ- SomeNick added to channel #channel access list as an auto-op. | |
79 | -> *ChanServ* access #channel list | |
80 | -ChanServ- Num Level Nick | |
81 | -ChanServ- 1 SOP MyNick | |
82 | -ChanServ- 2 AOP NotMyNick | |
83 | -ChanServ- 3 AOP SomeNick | |
84 | -> *ChanServ* access #channel list levels | |
85 | -ChanServ- Num Level Nick | |
86 | -ChanServ- 1 10 MyNick | |
87 | -ChanServ- 2 6 NotMyNick // Anything from AOP to SOP-1 is "AOP" | |
88 | -ChanServ- 3 5 SomeNick | |
89 | -> *ChanServ* access #channel list aop | |
90 | -ChanServ- Num Level Nick | |
91 | -ChanServ- 2 AOP NotMyNick | |
92 | -ChanServ- 3 AOP SomeNick | |
93 | ||
94 | Admittedly, the last examples are a bit questionable as they can let | |
95 | someone with the nick "levels" or "aop" hide from channel lists, but if | |
96 | that becomes a problem it's easy enough to forbid the nicknames/ | |
97 | ||
98 | The EXPERT option might work something like this: | |
99 | ||
100 | -> *ChanServ* levels #channel set memo 50 | |
101 | -ChanServ- The EXPERT option must be set to change access level settings. | |
102 | -> *ChanServ* set #channel expert on | |
103 | -ChanServ- The EXPERT option for #channel is now active. | |
104 | -> *ChanServ* levels #channel set memo 50 | |
105 | -ChanServ- Level MEMO on channel #channel changed to 50. | |
106 | -> *ChanServ* access #channel list | |
107 | -ChanServ- Num Level Nick | |
108 | -ChanServ- 1 10 MyNick | |
109 | -ChanServ- 2 5 SomeNick | |
110 | -> *ChanServ* access #channel list aop | |
111 | -ChanServ- AOP setting is disabled when EXPERT is set. | |
112 | -> *ChanServ* set #channel expert off | |
113 | -ChanServ- Warning: Disabling EXPERT will erase all access level changes. | |
114 | -ChanServ- Use SET #channel EXPERT OFF FORCE to disable EXPERT anyway. | |
115 | -> *ChanServ* set #channel expert off force | |
116 | -ChanServ- The EXPERT option for #channel has been disabled. | |
117 | -> *ChanServ* access #channel list | |
118 | -ChanServ- Num Level Nick | |
119 | -ChanServ- 1 SOP MyNick | |
120 | -ChanServ- 2 AOP SomeNick | |
121 | ||
122 | Incidentally, I could see *OP being done as a module which could be | |
123 | loaded or not at the server operator's choice. (Yes, I will try to get | |
124 | back onto that module thing RSN...) | |
125 | ||
126 | --Andrew Church | |
127 | <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at dragonfire.net</A> | |
128 | <A HREF="http://achurch.dragonfire.net/">http://achurch.dragonfire.net/</A> | |
129 | ||
130 | --------------------------------------------------------------- | |
131 | To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org</A> | |
132 | with "unsubscribe ircservices" in the body, without the quotes. | |
133 | ||
134 | ||
135 | </PRE> | |
136 | ||
137 | <!--endarticle--> | |
138 | <HR> | |
139 | <P><UL> | |
140 | <!--threads--> | |
141 | <LI>Previous message: <A HREF="000531.html">[IRCServices] IRC Services (fwd) | |
142 | </A></li> | |
143 | <LI>Next message: <A HREF="000534.html">[IRCServices] ACCESS and *OP | |
144 | </A></li> | |
145 | <LI> <B>Messages sorted by:</B> | |
146 | <a href="date.html#533">[ date ]</a> | |
147 | <a href="thread.html#533">[ thread ]</a> | |
148 | <a href="subject.html#533">[ subject ]</a> | |
149 | <a href="author.html#533">[ author ]</a> | |
150 | </LI> | |
151 | </UL> | |
152 | ||
153 | </body></html> |