]>
Commit | Line | Data |
---|---|---|
3bd189cb JR |
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> |
2 | <HTML> | |
3 | <HEAD> | |
4 | <TITLE> [IRCServices] Chanserv Kick command? | |
5 | </TITLE> | |
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="001892.html"> | |
11 | <LINK REL="Next" HREF="001894.html"> | |
12 | </HEAD> | |
13 | <BODY BGCOLOR="#ffffff"> | |
14 | <H1>[IRCServices] Chanserv Kick command?</H1> | |
15 | <B>Countersync</B> | |
16 | <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Chanserv%20Kick%20command%3F&In-Reply-To=" | |
17 | TITLE="[IRCServices] Chanserv Kick command?">countersync at hotmail.com | |
18 | </A><BR> | |
19 | <I>Sun May 20 05:42:01 PDT 2001</I> | |
20 | <P><UL> | |
21 | <LI>Previous message: <A HREF="001892.html">[IRCServices] Chanserv Kick command? | |
22 | </A></li> | |
23 | <LI>Next message: <A HREF="001894.html">[IRCServices] Chanserv Kick command? | |
24 | </A></li> | |
25 | <LI> <B>Messages sorted by:</B> | |
26 | <a href="date.html#1893">[ date ]</a> | |
27 | <a href="thread.html#1893">[ thread ]</a> | |
28 | <a href="subject.html#1893">[ subject ]</a> | |
29 | <a href="author.html#1893">[ author ]</a> | |
30 | </LI> | |
31 | </UL> | |
32 | <HR> | |
33 | <!--beginarticle--> | |
34 | <PRE>I actually think that there should be some sort of exposure of API calls for | |
35 | bots as well. So many times I've wanted an easy way to do mass status | |
36 | commands, retrieve an array of addresses only given a list of nicknames, | |
37 | perhaps even an option to use system compression/encryption codecs before | |
38 | sending messages between the server and client. Also; having an option to | |
39 | open DCC sessions to services (or telnet in to them if logged in to IRC) to | |
40 | bypass the regular network would also be an interesting idea. | |
41 | ||
42 | Anyway back to this thread's idea. It would be REALLY interesting if the | |
43 | services had not only the ability to do anything a channel op can do, but | |
44 | also the option to give users the ability to only do certain things, a | |
45 | method of going beyond simple at level X you can do this. Perhaps a group | |
46 | method, perhaps something similar to Unix file permissions (which on most | |
47 | systems have different ways of accessing the actual storage of data. Such | |
48 | as a more verbose structure for normal users, which separates different | |
49 | options in to actual word phrases or simple yes/no choices. Verses the hex | |
50 | or octal modes that allow for much shorter setting by just doing the raw | |
51 | bitlevel.) | |
52 | ||
53 | Places that this would be extremely useful are if you have a user that you | |
54 | trust with invites, but don't want to allow them access to being an actual | |
55 | op. Or if you have a bot that is just supposed to do voice issues but not | |
56 | any kicks/bans/etc. There are variations upon these themes, however these | |
57 | are the most common ones that I've seen. | |
58 | ||
59 | The ideal layout for services would be having EVERYTHING in modules. There | |
60 | would be defined interfaces for each module. Each module would become it's | |
61 | own thread(s), and even code tree. For example if there was a kick module, | |
62 | when a user asks it to do something, there would be a standard "Can this | |
63 | user do X" call within the access module. This module could then use | |
64 | whatever method the compiler/administrators saw fit to include. It would no | |
65 | longer matter where or how the databases were stored, or how each component | |
66 | worked. They would evolve separately like TCP/IP. | |
67 | ||
68 | Additionally there would be different interaction versions. Optionally | |
69 | legacy support in future versions for named older modules, perhaps even | |
70 | wrapper modules to ease transitions. Right now this is about as detailed as | |
71 | I can get. I believe that I understand the general concepts of programming, | |
72 | however I do not know the actual ramifications of what I ask. I have no | |
73 | clue how easy/difficult these would be do to. From what I do know this | |
74 | seems to be the most logical and productive path. Speaking of that, | |
75 | labeling from individual sub-routines up would help some other ideas that I | |
76 | have for the future. Especially if each were maintained by a single person | |
77 | and had a defined structure for passing variables if it were to be exposed; | |
78 | actually I guess that would have to be anyway. | |
79 | ||
80 | Sorry for being this long and just dropping this. I just started typing and | |
81 | somewhere along the line I realized that now was probably the right time to | |
82 | insert my 'grandiose' ideas. Especially since having a more realistic look | |
83 | on the future I won't be good enough to even think of taking on a project | |
84 | this big for about 1 year if I work hard; which I'm going to have to do for | |
85 | the college I'm planning to attend. So that optimistic figure is not likely | |
86 | to be realistic. | |
87 | ----- Original Message ----- | |
88 | From: "Daniel" <<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">dan_jr at ultim.net</A>> | |
89 | Sent: Sunday, May 20, 2001 01:30 | |
90 | ><i> Of course .. | |
91 | </I>><i> | |
92 | </I>><i> But is very useful sometime to use chanserv to kick someone | |
93 | </I>><i> | |
94 | </I>><i> like to voice someone with it! | |
95 | </I>><i> | |
96 | </I>><i> I know it is easy to add as function in. and im suggesting it | |
97 | </I>><i> for the next release.. | |
98 | </I>><i> I mean.. I use operserv to kick someone in channel sometime | |
99 | </I>><i> but regular chaops can't and any regular bots or other services | |
100 | </I>><i> can use kick command into chanserv.. | |
101 | </I>><i> -----Original Message----- | |
102 | </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 | |
103 | </I>><i> Sent: 19 mai, 2001 20:04 | |
104 | </I>><i> >I would like to know | |
105 | </I>><i> > | |
106 | </I>><i> >if there is any possibility to add a KICK command to chanserv | |
107 | </I>><i> >like operserv have! | |
108 | </I>><i> | |
109 | </I>><i> Why is a regular /kick insufficient? | |
110 | </I>><i> | |
111 | </I>><i> --Andrew Church | |
112 | </I>><i> <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at achurch.org</A> | |
113 | </I>><i> <A HREF="http://achurch.org/">http://achurch.org/</A> | |
114 | </I> | |
115 | </PRE> | |
116 | ||
117 | <!--endarticle--> | |
118 | <HR> | |
119 | <P><UL> | |
120 | <!--threads--> | |
121 | <LI>Previous message: <A HREF="001892.html">[IRCServices] Chanserv Kick command? | |
122 | </A></li> | |
123 | <LI>Next message: <A HREF="001894.html">[IRCServices] Chanserv Kick command? | |
124 | </A></li> | |
125 | <LI> <B>Messages sorted by:</B> | |
126 | <a href="date.html#1893">[ date ]</a> | |
127 | <a href="thread.html#1893">[ thread ]</a> | |
128 | <a href="subject.html#1893">[ subject ]</a> | |
129 | <a href="author.html#1893">[ author ]</a> | |
130 | </LI> | |
131 | </UL> | |
132 | ||
133 | </body></html> |