1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices] Chanserv Kick command?
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Chanserv%20Kick%20command%3F&In-Reply-To=">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"001893.html">
11 <LINK REL=
"Next" HREF=
"001895.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices] Chanserv Kick command?
</H1>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Chanserv%20Kick%20command%3F&In-Reply-To="
17 TITLE=
"[IRCServices] Chanserv Kick command?">achurch at achurch.org
19 <I>Sun May
20 06:
50:
01 PDT
2001</I>
21 <LI>Previous message:
<A HREF=
"001893.html">[IRCServices] Chanserv Kick command?
23 <LI>Next message:
<A HREF=
"001895.html">[IRCServices] Something for next big release of Services?
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#1894">[ date ]
</a>
27 <a href=
"thread.html#1894">[ thread ]
</a>
28 <a href=
"subject.html#1894">[ subject ]
</a>
29 <a href=
"author.html#1894">[ author ]
</a>
34 <PRE> While you do present some interesting ideas, they're not realistically
35 very feasible (translation: I don't wanna). I can't blame you for trying,
36 but as you say and your message shows, you're not very experienced in
37 programming, particularly real-world programming; one of the key things you
38 learn is that if you want to actually get anything done, you have to forget
39 everything your teachers ever taught you about programming.
41 Okay, I'm exaggerating a bit there, but trying for a perfect program
42 design makes the actual implementation hell. The best real-world design
43 for a program is one that is not so sloppy that it can't be maintained
44 easily, but not so elegant that you get more
"metacode
" (procedure headers,
45 dynamic link management, etc.) than code for the guts of the program
46 itself. The former leads to mountains of bugs and slow code development;
47 the latter leads to hills of bugs (because you have to copy the same code
48 over and over, increasing the likelihood of a mistake) and, again, slow
49 code development. In fact, the primary motivation behind my redesign of
50 Services for version
5.0 is that it's grown to over four times its original
51 (version
1.0) size and is leaning toward the
"sloppy
" category now.
53 One other comment: Having more people working on the program doesn't
54 necessarily mean more productivity--people have to communicate, decide on
55 things, have arguments, and so on. You might try reading Fred Brooks'
56 "The Mythical Man-Month
" sometime; while it's centered more on really big
57 projects that take dozens or hundreds of people, it still makes a number of
58 good points about program development in general.
60 Anyway, they're good thoughts; you're welcome to try them on your own
61 if you like, but I'll pass.
64 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at achurch.org
</A>
65 <A HREF=
"http://achurch.org/">http://achurch.org/
</A>
67 ><i>I actually think that there should be some sort of exposure of API calls for
68 </I>><i>bots as well. So many times I've wanted an easy way to do mass status
69 </I>><i>commands, retrieve an array of addresses only given a list of nicknames,
70 </I>><i>perhaps even an option to use system compression/encryption codecs before
71 </I>><i>sending messages between the server and client. Also; having an option to
72 </I>><i>open DCC sessions to services (or telnet in to them if logged in to IRC) to
73 </I>><i>bypass the regular network would also be an interesting idea.
75 </I>><i>Anyway back to this thread's idea. It would be REALLY interesting if the
76 </I>><i>services had not only the ability to do anything a channel op can do, but
77 </I>><i>also the option to give users the ability to only do certain things, a
78 </I>><i>method of going beyond simple at level X you can do this. Perhaps a group
79 </I>><i>method, perhaps something similar to Unix file permissions (which on most
80 </I>><i>systems have different ways of accessing the actual storage of data. Such
81 </I>><i>as a more verbose structure for normal users, which separates different
82 </I>><i>options in to actual word phrases or simple yes/no choices. Verses the hex
83 </I>><i>or octal modes that allow for much shorter setting by just doing the raw
86 </I>><i>Places that this would be extremely useful are if you have a user that you
87 </I>><i>trust with invites, but don't want to allow them access to being an actual
88 </I>><i>op. Or if you have a bot that is just supposed to do voice issues but not
89 </I>><i>any kicks/bans/etc. There are variations upon these themes, however these
90 </I>><i>are the most common ones that I've seen.
92 </I>><i>The ideal layout for services would be having EVERYTHING in modules. There
93 </I>><i>would be defined interfaces for each module. Each module would become it's
94 </I>><i>own thread(s), and even code tree. For example if there was a kick module,
95 </I>><i>when a user asks it to do something, there would be a standard
"Can this
96 </I>><i>user do X
" call within the access module. This module could then use
97 </I>><i>whatever method the compiler/administrators saw fit to include. It would no
98 </I>><i>longer matter where or how the databases were stored, or how each component
99 </I>><i>worked. They would evolve separately like TCP/IP.
101 </I>><i>Additionally there would be different interaction versions. Optionally
102 </I>><i>legacy support in future versions for named older modules, perhaps even
103 </I>><i>wrapper modules to ease transitions. Right now this is about as detailed as
104 </I>><i>I can get. I believe that I understand the general concepts of programming,
105 </I>><i>however I do not know the actual ramifications of what I ask. I have no
106 </I>><i>clue how easy/difficult these would be do to. From what I do know this
107 </I>><i>seems to be the most logical and productive path. Speaking of that,
108 </I>><i>labeling from individual sub-routines up would help some other ideas that I
109 </I>><i>have for the future. Especially if each were maintained by a single person
110 </I>><i>and had a defined structure for passing variables if it were to be exposed;
111 </I>><i>actually I guess that would have to be anyway.
113 </I>><i>Sorry for being this long and just dropping this. I just started typing and
114 </I>><i>somewhere along the line I realized that now was probably the right time to
115 </I>><i>insert my 'grandiose' ideas. Especially since having a more realistic look
116 </I>><i>on the future I won't be good enough to even think of taking on a project
117 </I>><i>this big for about
1 year if I work hard; which I'm going to have to do for
118 </I>><i>the college I'm planning to attend. So that optimistic figure is not likely
119 </I>><i>to be realistic.
120 </I>><i>----- Original Message -----
121 </I>><i>From:
"Daniel
" <<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">dan_jr at ultim.net
</A>>
122 </I>><i>Sent: Sunday, May
20,
2001 01:
30
123 </I>>><i> Of course ..
125 </I>>><i> But is very useful sometime to use chanserv to kick someone
127 </I>>><i> like to voice someone with it!
129 </I>>><i> I know it is easy to add as function in. and im suggesting it
130 </I>>><i> for the next release..
131 </I>>><i> I mean.. I use operserv to kick someone in channel sometime
132 </I>>><i> but regular chaops can't and any regular bots or other services
133 </I>>><i> can use kick command into chanserv..
134 </I>>><i> -----Original Message-----
135 </I>>><i> [mailto:
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices-admin at ircservices.za.net
</A>]On Behalf Of Andrew Church
136 </I>>><i> Sent:
19 mai,
2001 20:
04
137 </I>>><i> >I would like to know
139 </I>>><i> >if there is any possibility to add a KICK command to chanserv
140 </I>>><i> >like operserv have!
142 </I>>><i> Why is a regular /kick insufficient?
144 </I>>><i> --Andrew Church
145 </I>>><i> <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at achurch.org
</A>
146 </I>>><i> <A HREF=
"http://achurch.org/">http://achurch.org/
</A>
147 </I>><i>-----------------------------------------------------------
148 </I>><i>To unsubscribe, mail
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices-request at ircservices.za.net
</A>
149 </I>><i>with the word UNSUBSCRIBE in the subject of the mail.
150 </I>><i><A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">http://www.ircservices.za.net/mailman/listinfo/ircservices
</A>
158 <LI>Previous message:
<A HREF=
"001893.html">[IRCServices] Chanserv Kick command?
160 <LI>Next message:
<A HREF=
"001895.html">[IRCServices] Something for next big release of Services?
162 <LI> <B>Messages sorted by:
</B>
163 <a href=
"date.html#1894">[ date ]
</a>
164 <a href=
"thread.html#1894">[ thread ]
</a>
165 <a href=
"subject.html#1894">[ subject ]
</a>
166 <a href=
"author.html#1894">[ author ]
</a>
projects / irc.git / blob