[IRCServices] ACCESS and *OP
Andrew Church
achurch at dragonfire.net
Sat May 13 01:37:19 PDT 2000
>How would everyone fell if we removed the ACCESS command and replaced it
>with AOP SOP etc? This would simplify things dramatically and I know it
>would affect those people who want very customisable channel access
>levels.
This is a bit late because I haven't had Internet access for the past
two weeks (just moved to a new apartment), but here's my two cents on the
subject.
Without touching (yet) the subject of A/S/VOP, I'm very strongly
against the removal of the ACCESS command. While I have to admit part of
that is the fact that I created that system and happen to like it, there
are a couple of other big problems that would crop up:
1) You don't just remove a feature without warning or everyone who's
been using that feature gets screwed. Some people on the mailing list
have already mentioned it, but there are people who are perfectly used to
the current ACCESS command and in fact don't even know about AOP/SOP/etc.
2) Converting current channel databases to work without ACCESS would
be a nightmare, and even in the best scenario some settings would be lost.
Do you want to tell a user "we upgraded our software and now you can't do
this anymore"?
As for the addition of AOP/SOP/etc commands, I am not overly against
them except inasmuch as they represent a "standard" that doesn't have to
be a standard; I also remember quite well the numerous complaints that
people found the level system difficult to use. On the other hand, I have
come to detest the attitude of Microsoft (among others) to do their best
to keep you ignorant even if you know what you're doing, and taking out
the ACCESS command would be too close to that for my liking. What I would
recommend is to add the *OP functions, either as commands or as
alternatives for the ACCESS ADD level value, and have those functions in
turn call ACCESS ADD with an appropriate level. Naturally, this would not
work if the channel levels had been changed, but by adding an EXPERT
channel option as someone else suggested and disallowing level changes
without EXPERT set, AOP/SOP/etc become workable again under the ACCESS
system.
My personal preference is to use *OP as an option to the ACCESS ADD
command, and display levels by name in LIST if EXPERT is not set. The
user/Services dialogue would look something like this:
-> *ChanServ* access #channel add SomeNick sop
-ChanServ- SomeNick added to channel #channel access list as an auto-op.
-> *ChanServ* access #channel list
-ChanServ- Num Level Nick
-ChanServ- 1 SOP MyNick
-ChanServ- 2 AOP NotMyNick
-ChanServ- 3 AOP SomeNick
-> *ChanServ* access #channel list levels
-ChanServ- Num Level Nick
-ChanServ- 1 10 MyNick
-ChanServ- 2 6 NotMyNick // Anything from AOP to SOP-1 is "AOP"
-ChanServ- 3 5 SomeNick
-> *ChanServ* access #channel list aop
-ChanServ- Num Level Nick
-ChanServ- 2 AOP NotMyNick
-ChanServ- 3 AOP SomeNick
Admittedly, the last examples are a bit questionable as they can let
someone with the nick "levels" or "aop" hide from channel lists, but if
that becomes a problem it's easy enough to forbid the nicknames/
The EXPERT option might work something like this:
-> *ChanServ* levels #channel set memo 50
-ChanServ- The EXPERT option must be set to change access level settings.
-> *ChanServ* set #channel expert on
-ChanServ- The EXPERT option for #channel is now active.
-> *ChanServ* levels #channel set memo 50
-ChanServ- Level MEMO on channel #channel changed to 50.
-> *ChanServ* access #channel list
-ChanServ- Num Level Nick
-ChanServ- 1 10 MyNick
-ChanServ- 2 5 SomeNick
-> *ChanServ* access #channel list aop
-ChanServ- AOP setting is disabled when EXPERT is set.
-> *ChanServ* set #channel expert off
-ChanServ- Warning: Disabling EXPERT will erase all access level changes.
-ChanServ- Use SET #channel EXPERT OFF FORCE to disable EXPERT anyway.
-> *ChanServ* set #channel expert off force
-ChanServ- The EXPERT option for #channel has been disabled.
-> *ChanServ* access #channel list
-ChanServ- Num Level Nick
-ChanServ- 1 SOP MyNick
-ChanServ- 2 AOP SomeNick
Incidentally, I could see *OP being done as a module which could be
loaded or not at the server operator's choice. (Yes, I will try to get
back onto that module thing RSN...)
--Andrew Church
achurch at dragonfire.net
http://achurch.dragonfire.net/
---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.