1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> AW: [IRCServices] ACCESS and *OP
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=AW%3A%20%5BIRCServices%5D%20ACCESS%20and%20%2AOP&In-Reply-To=391c4228.01476%40dragonfire.net">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"000534.html">
11 <LINK REL=
"Next" HREF=
"000535.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>AW: [IRCServices] ACCESS and *OP
</H1>
15 <B>Yusuf Iskenderoglu
</B>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=AW%3A%20%5BIRCServices%5D%20ACCESS%20and%20%2AOP&In-Reply-To=391c4228.01476%40dragonfire.net"
17 TITLE=
"AW: [IRCServices] ACCESS and *OP">uhc0 at rz.uni-karlsruhe.de
19 <I>Sat May
13 11:
56:
43 PDT
2000</I>
21 <LI>Previous message:
<A HREF=
"000534.html">[IRCServices] ACCESS and *OP
23 <LI>Next message:
<A HREF=
"000535.html">[IRCServices] ACCESS and *OP
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#536">[ date ]
</a>
27 <a href=
"thread.html#536">[ thread ]
</a>
28 <a href=
"subject.html#536">[ subject ]
</a>
29 <a href=
"author.html#536">[ author ]
</a>
37 I also wanted to tell my personal opinion about this topic,
38 for it is still being discussed.
40 On those IRC Networks, I got used to chat, people are heavily used to use
42 as a command, rather than *OP. Helping to manage some sorts of #help
44 even say, that, there are very seldom, users that want to get an
45 explaination, why they
46 have to use ACCESS, for they were used to use *OP.
48 In order to keep consistency with the access levels, those commands might be
50 alias commands, ( VOP corresponds to autovoice level, AOP to autoop level,
51 and SOP to the highest one between acc-change and akick level ) I do not see
52 any positive aspect in changing the whole system to *OP.
54 Though haven't said new things,
55 I just wanted to share my point of view.
60 ---------------------------------
62 eMail -
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">uhc0 at rz.uni-karlsruhe.de
</A>
63 eMail -
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">s_iskend at ira.uka.de
</A>
64 ICQ :
20587464 \ TimeMr14C
65 ---------------------------------
67 ><i> -----Urspr
üngliche Nachricht-----
68 </I>><i> Von:
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">owner-ircservices at ender.shadowfire.org
</A>
69 </I>><i> [mailto:
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">owner-ircservices at ender.shadowfire.org
</A>]Im Auftrag von Andrew
71 </I>><i> Gesendet: Freitag,
12. Mai
2000 18:
37
72 </I>><i> An:
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices at ender.shadowfire.org
</A>
73 </I>><i> Betreff: [IRCServices] ACCESS and *OP
76 </I>><i> >How would everyone fell if we removed the ACCESS command and replaced it
77 </I>><i> >with AOP SOP etc? This would simplify things dramatically and I know it
78 </I>><i> >would affect those people who want very customisable channel access
79 </I>><i> >levels.
81 </I>><i> This is a bit late because I haven't had Internet access for the past
82 </I>><i> two weeks (just moved to a new apartment), but here's my two cents on the
85 </I>><i> Without touching (yet) the subject of A/S/VOP, I'm very strongly
86 </I>><i> against the removal of the ACCESS command. While I have to admit part of
87 </I>><i> that is the fact that I created that system and happen to like it, there
88 </I>><i> are a couple of other big problems that would crop up:
90 </I>><i> 1) You don't just remove a feature without warning or everyone who's
91 </I>><i> been using that feature gets screwed. Some people on the mailing list
92 </I>><i> have already mentioned it, but there are people who are perfectly used to
93 </I>><i> the current ACCESS command and in fact don't even know about AOP/SOP/etc.
95 </I>><i> 2) Converting current channel databases to work without ACCESS would
96 </I>><i> be a nightmare, and even in the best scenario some settings would be lost.
97 </I>><i> Do you want to tell a user
"we upgraded our software and now you can't do
98 </I>><i> this anymore
"?
100 </I>><i> As for the addition of AOP/SOP/etc commands, I am not overly against
101 </I>><i> them except inasmuch as they represent a
"standard
" that doesn't have to
102 </I>><i> be a standard; I also remember quite well the numerous complaints that
103 </I>><i> people found the level system difficult to use. On the other hand, I have
104 </I>><i> come to detest the attitude of Microsoft (among others) to do their best
105 </I>><i> to keep you ignorant even if you know what you're doing, and taking out
106 </I>><i> the ACCESS command would be too close to that for my liking. What I would
107 </I>><i> recommend is to add the *OP functions, either as commands or as
108 </I>><i> alternatives for the ACCESS ADD level value, and have those functions in
109 </I>><i> turn call ACCESS ADD with an appropriate level. Naturally, this would not
110 </I>><i> work if the channel levels had been changed, but by adding an EXPERT
111 </I>><i> channel option as someone else suggested and disallowing level changes
112 </I>><i> without EXPERT set, AOP/SOP/etc become workable again under the ACCESS
115 </I>><i> My personal preference is to use *OP as an option to the ACCESS ADD
116 </I>><i> command, and display levels by name in LIST if EXPERT is not set. The
117 </I>><i> user/Services dialogue would look something like this:
119 </I>><i> -
> *ChanServ* access #channel add SomeNick sop
120 </I>><i> -ChanServ- SomeNick added to channel #channel access list as an auto-op.
121 </I>><i> -
> *ChanServ* access #channel list
122 </I>><i> -ChanServ- Num Level Nick
123 </I>><i> -ChanServ-
1 SOP MyNick
124 </I>><i> -ChanServ-
2 AOP NotMyNick
125 </I>><i> -ChanServ-
3 AOP SomeNick
126 </I>><i> -
> *ChanServ* access #channel list levels
127 </I>><i> -ChanServ- Num Level Nick
128 </I>><i> -ChanServ-
1 10 MyNick
129 </I>><i> -ChanServ-
2 6 NotMyNick // Anything from AOP to SOP-
1 is
"AOP
"
130 </I>><i> -ChanServ-
3 5 SomeNick
131 </I>><i> -
> *ChanServ* access #channel list aop
132 </I>><i> -ChanServ- Num Level Nick
133 </I>><i> -ChanServ-
2 AOP NotMyNick
134 </I>><i> -ChanServ-
3 AOP SomeNick
136 </I>><i> Admittedly, the last examples are a bit questionable as they can let
137 </I>><i> someone with the nick
"levels
" or
"aop
" hide from channel lists, but if
138 </I>><i> that becomes a problem it's easy enough to forbid the nicknames/
140 </I>><i> The EXPERT option might work something like this:
142 </I>><i> -
> *ChanServ* levels #channel set memo
50
143 </I>><i> -ChanServ- The EXPERT option must be set to change access level settings.
144 </I>><i> -
> *ChanServ* set #channel expert on
145 </I>><i> -ChanServ- The EXPERT option for #channel is now active.
146 </I>><i> -
> *ChanServ* levels #channel set memo
50
147 </I>><i> -ChanServ- Level MEMO on channel #channel changed to
50.
148 </I>><i> -
> *ChanServ* access #channel list
149 </I>><i> -ChanServ- Num Level Nick
150 </I>><i> -ChanServ-
1 10 MyNick
151 </I>><i> -ChanServ-
2 5 SomeNick
152 </I>><i> -
> *ChanServ* access #channel list aop
153 </I>><i> -ChanServ- AOP setting is disabled when EXPERT is set.
154 </I>><i> -
> *ChanServ* set #channel expert off
155 </I>><i> -ChanServ- Warning: Disabling EXPERT will erase all access level changes.
156 </I>><i> -ChanServ- Use SET #channel EXPERT OFF FORCE to disable EXPERT anyway.
157 </I>><i> -
> *ChanServ* set #channel expert off force
158 </I>><i> -ChanServ- The EXPERT option for #channel has been disabled.
159 </I>><i> -
> *ChanServ* access #channel list
160 </I>><i> -ChanServ- Num Level Nick
161 </I>><i> -ChanServ-
1 SOP MyNick
162 </I>><i> -ChanServ-
2 AOP SomeNick
164 </I>><i> Incidentally, I could see *OP being done as a module which could be
165 </I>><i> loaded or not at the server operator's choice. (Yes, I will try to get
166 </I>><i> back onto that module thing RSN...)
168 </I>><i> --Andrew Church
169 </I>><i> <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at dragonfire.net
</A>
170 </I>><i> <A HREF=
"<A HREF=
"http://achurch.dragonfire.net/"">http://achurch.dragonfire.net/
"</A>><A HREF=
"http://achurch.dragonfire.net/</A">http://achurch.dragonfire.net/
</A
</A>>
172 </I>><i> ---------------------------------------------------------------
173 </I>><i> To unsubscribe, send email to
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org
</A>
174 </I>><i> with
"unsubscribe ircservices
" in the body, without the quotes.
178 ---------------------------------------------------------------
179 To unsubscribe, send email to
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org
</A>
180 with
"unsubscribe ircservices
" in the body, without the quotes.
189 <LI>Previous message:
<A HREF=
"000534.html">[IRCServices] ACCESS and *OP
191 <LI>Next message:
<A HREF=
"000535.html">[IRCServices] ACCESS and *OP
193 <LI> <B>Messages sorted by:
</B>
194 <a href=
"date.html#536">[ date ]
</a>
195 <a href=
"thread.html#536">[ thread ]
</a>
196 <a href=
"subject.html#536">[ subject ]
</a>
197 <a href=
"author.html#536">[ author ]
</a>
projects / irc.git / blob