[IRCServices Coding] Feature Suggestions

[Andrew Church]

     To the original poster: Don't use HTML mail on this list.

>> 1. /ns set autoop [on|off] - Just like Anope
>
>If this is what I think it is, which is that the nick in question
>won't be auto-opped on any channel (next time please elaborate on what
>Anope does), I believe that Andrew may have been considering this at
>one point (I think it was in one of the TODO lists). That being said,
>I haven't seen this in 5.1, so it may have been dropped or thrown out.

     I've never seen the point to this option (if you don't want auto-ops,
don't have people give you auto-op access), so I won't be adding it.

>> 2. I think channel passwords suck, so:
[...]

     I agree, but removing them at this point is not feasible, so I've left
it documented as something for future developers to think about (technical
manual section 11).

>> 3. /cs clear #channel users - make this only kick users who don't have the
>> access to use it.

     I'd rather keep it the way it is--kick everybody out and let the users
sort things out afterwards.  (Changing it as you suggest would undoubtedly
leave users wondering "why didn't user X get kicked?")

>> 4. When someone sets a new founder for the channel, they immediately lose
>> their founder-level access.

     This is already the case (unless the founder used the IDENTIFY command
to gain privileges, in which case there would be no point in dropping
privileges because he could just identify again).

>> 5. /ns listchans - make this list all of the user's channel accesses, like
>> /ns alist in Anope
>
>If I understand you correctly, you want this to display the access
>list for a channel as well. Services already does this. (/msg ChanServ
>ACCESS #channel LIST - or something like that)

     I think the intention was a new command to list every channel the user
has a nonzero access level on, along with that access level.  I don't see
that as necessary, because (as you say) ChanServ ACCESS can already display
the access level of a particular list; also, the time required to search
through all access lists of all channels could be prohibitively long on
large networks.

>> 6. When someone does /cs info #channel, and it shows the mode lock, make it
>> show the locked mode paramaters too.
>
>Bad idea. I'm sure that no-one wants to see their channel key
>displayed in this manner. :)

     Exactly.  As for other modes, just look at the channel's current mode
set, which will naturally be the same as what's set in the mode lock.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/