AW: [IRCServices] ACCESS and *OP

[Yusuf Iskenderoglu]

Hello;

I also wanted to tell my personal opinion about this topic,
for it is still being discussed.

On those IRC Networks, I got used to chat, people are heavily used to use
ACCESS
as a command, rather than *OP. Helping to manage some sorts of #help
channels, I can
even say, that, there are very seldom, users that want to get an
explaination, why they
have to use ACCESS, for they were used to use *OP.

In order to keep consistency with the access levels, those commands might be
added as
alias commands, ( VOP corresponds to autovoice level, AOP to autoop level,
and SOP to the highest one between acc-change and akick level ) I do not see
any positive aspect in changing the whole system to *OP.

Though haven't said new things,
I just wanted to share my point of view.

sincerely yours,
yusuf

---------------------------------
Yusuf Iskenderoglu
eMail - uhc0 at rz.uni-karlsruhe.de
eMail - s_iskend at ira.uka.de
ICQ : 20587464 \ TimeMr14C
---------------------------------

> -----Ursprüngliche Nachricht-----
> Von: owner-ircservices at ender.shadowfire.org
> [mailto:owner-ircservices at ender.shadowfire.org]Im Auftrag von Andrew
> Church
> Gesendet: Freitag, 12. Mai 2000 18:37
> An: ircservices at ender.shadowfire.org
> Betreff: [IRCServices] ACCESS and *OP
>
>
> >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
>     <A  HREF="http://achurch.dragonfire.net/">http://achurch.dragonfire.net/</A>
>
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo at ender.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.
>


---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.