[IRCServices] Chanserv Kick command?

[Andrew Church]

     While you do present some interesting ideas, they're not realistically
very feasible (translation: I don't wanna).  I can't blame you for trying,
but as you say and your message shows, you're not very experienced in
programming, particularly real-world programming; one of the key things you
learn is that if you want to actually get anything done, you have to forget
everything your teachers ever taught you about programming.

     Okay, I'm exaggerating a bit there, but trying for a perfect program
design makes the actual implementation hell.  The best real-world design
for a program is one that is not so sloppy that it can't be maintained
easily, but not so elegant that you get more "metacode" (procedure headers,
dynamic link management, etc.) than code for the guts of the program
itself.  The former leads to mountains of bugs and slow code development;
the latter leads to hills of bugs (because you have to copy the same code
over and over, increasing the likelihood of a mistake) and, again, slow
code development.  In fact, the primary motivation behind my redesign of
Services for version 5.0 is that it's grown to over four times its original
(version 1.0) size and is leaning toward the "sloppy" category now.

     One other comment:  Having more people working on the program doesn't
necessarily mean more productivity--people have to communicate, decide on
things, have arguments, and so on.  You might try reading Fred Brooks'
"The Mythical Man-Month" sometime; while it's centered more on really big
projects that take dozens or hundreds of people, it still makes a number of
good points about program development in general.

     Anyway, they're good thoughts; you're welcome to try them on your own
if you like, but I'll pass.

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

>I actually think that there should be some sort of exposure of API calls for
>bots as well.  So many times I've wanted an easy way to do mass status
>commands, retrieve an array of addresses only given a list of nicknames,
>perhaps even an option to use system compression/encryption codecs before
>sending messages between the server and client.  Also; having an option to
>open DCC sessions to services (or telnet in to them if logged in to IRC) to
>bypass the regular network would also be an interesting idea.
>
>Anyway back to this thread's idea.  It would be REALLY interesting if the
>services had not only the ability to do anything a channel op can do, but
>also the option to give users the ability to only do certain things, a
>method of going beyond simple at level X you can do this.  Perhaps a group
>method, perhaps something similar to Unix file permissions (which on most
>systems have different ways of accessing the actual storage of data.  Such
>as a more verbose structure for normal users, which separates different
>options in to actual word phrases or simple yes/no choices.  Verses the hex
>or octal modes that allow for much shorter setting by just doing the raw
>bitlevel.)
>
>Places that this would be extremely useful are if you have a user that you
>trust with invites, but don't want to allow them access to being an actual
>op.  Or if you have a bot that is just supposed to do voice issues but not
>any kicks/bans/etc.  There are variations upon these themes, however these
>are the most common ones that I've seen.
>
>The ideal layout for services would be having EVERYTHING in modules.  There
>would be defined interfaces for each module.  Each module would become it's
>own thread(s), and even code tree.  For example if there was a kick module,
>when a user asks it to do something, there would be a standard "Can this
>user do X" call within the access module.  This module could then use
>whatever method the compiler/administrators saw fit to include.  It would no
>longer matter where or how the databases were stored, or how each component
>worked.  They would evolve separately like TCP/IP.
>
>Additionally there would be different interaction versions.  Optionally
>legacy support in future versions for named older modules, perhaps even
>wrapper modules to ease transitions.  Right now this is about as detailed as
>I can get.  I believe that I understand the general concepts of programming,
>however I do not know the actual ramifications of what I ask.  I have no
>clue how easy/difficult these would be do to.  From what I do know this
>seems to be the most logical and productive path.  Speaking of that,
>labeling from individual sub-routines up would help some other ideas that I
>have for the future.  Especially if each were maintained by a single person
>and had a defined structure for passing variables if it were to be exposed;
>actually I guess that would have to be anyway.
>
>Sorry for being this long and just dropping this.  I just started typing and
>somewhere along the line I realized that now was probably the right time to
>insert my 'grandiose' ideas.  Especially since having a more realistic look
>on the future I won't be good enough to even think of taking on a project
>this big for about 1 year if I work hard; which I'm going to have to do for
>the college I'm planning to attend.  So that optimistic figure is not likely
>to be realistic.
>----- Original Message -----
>From: "Daniel" <dan_jr at ultim.net>
>Sent: Sunday, May 20, 2001 01:30
>> Of course ..
>>
>> But is very useful sometime to use chanserv to kick someone
>>
>> like to voice someone with it!
>>
>> I know it is easy to add as function in.  and im suggesting it
>> for the next release..
>> I mean..  I use operserv to kick someone in channel sometime
>> but regular chaops can't and any regular bots or other services
>> can use kick command into chanserv..
>> -----Original Message-----
>> [mailto:ircservices-admin at ircservices.za.net]On Behalf Of Andrew Church
>> Sent: 19 mai, 2001 20:04
>> >I would like to know
>> >
>> >if there is any possibility to add a KICK command to chanserv
>> >like operserv have!
>>
>>      Why is a regular /kick insufficient?
>>
>>   --Andrew Church
>>     achurch at achurch.org
>>     http://achurch.org/
>-----------------------------------------------------------
>To unsubscribe, mail ircservices-request at ircservices.za.net
>with the word UNSUBSCRIBE in the subject of the mail.
>http://www.ircservices.za.net/mailman/listinfo/ircservices