]>
Commit | Line | Data |
---|---|---|
3bd189cb JR |
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> |
2 | <HTML> | |
3 | <HEAD> | |
4 | <TITLE> [IRCServices Coding] Which route to take - Module? | |
5 | </TITLE> | |
6 | <LINK REL="Index" HREF="index.html" > | |
7 | <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Which%20route%20to%20take%20-%20Module%3F&In-Reply-To=5.2.1.1.0.20030903223929.016e4648%40mail.elric.net"> | |
8 | <META NAME="robots" CONTENT="index,nofollow"> | |
9 | <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> | |
10 | <LINK REL="Previous" HREF="002200.html"> | |
11 | <LINK REL="Next" HREF="002203.html"> | |
12 | </HEAD> | |
13 | <BODY BGCOLOR="#ffffff"> | |
14 | <H1>[IRCServices Coding] Which route to take - Module?</H1> | |
15 | <B>Yusuf Iskenderoglu</B> | |
16 | <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Which%20route%20to%20take%20-%20Module%3F&In-Reply-To=5.2.1.1.0.20030903223929.016e4648%40mail.elric.net" | |
17 | TITLE="[IRCServices Coding] Which route to take - Module?">uhc0 at rz.uni-karlsruhe.de | |
18 | </A><BR> | |
19 | <I>Thu Sep 4 01:34:06 PDT 2003</I> | |
20 | <P><UL> | |
21 | <LI>Previous message: <A HREF="002200.html">[IRCServices Coding] Which route to take - Module? | |
22 | </A></li> | |
23 | <LI>Next message: <A HREF="002203.html">[IRCServices Coding] Which route to take - Module? | |
24 | </A></li> | |
25 | <LI> <B>Messages sorted by:</B> | |
26 | <a href="date.html#2756">[ date ]</a> | |
27 | <a href="thread.html#2756">[ thread ]</a> | |
28 | <a href="subject.html#2756">[ subject ]</a> | |
29 | <a href="author.html#2756">[ author ]</a> | |
30 | </LI> | |
31 | </UL> | |
32 | <HR> | |
33 | <!--beginarticle--> | |
34 | <PRE>Hello; | |
35 | ||
36 | Long question; long answer. | |
37 | First of all, you must come off the thoughts of "Against the RFC". | |
38 | Why? Because, tons of irc servers available do provide techniques, which | |
39 | do not appear, or appear differently on the irc RFC, so that by design | |
40 | these ircds are also against it. In most of the cases, these changes | |
41 | reflect themselves in their appropriate server-to-server protocols, and | |
42 | become transient to the clients, so that on client side, the protocol | |
43 | remains original. This is also the only way of ensuring that all of the | |
44 | clients can work with a specific irc daemon. | |
45 | ||
46 | The issue, why PRIVMSG instead of NOTICE is bad, does also result from | |
47 | the client-to-server part of the RFC. And it has a reason. Consider two | |
48 | automated clients (bots, services, etc) talking to each other with | |
49 | PRIVMSG, and saying things like: | |
50 | <NickServ> otherwise, I change your nick. | |
51 | <MyBot> Unknown command otherwise. Please repeat your query. | |
52 | <NickServ> Unknown command UNKNOWN. | |
53 | <MyBot> Unknown command unknown. Please repeat your query. | |
54 | <NickServ> Unknown command UNKNOWN. | |
55 | <MyBot> Unknown command unknown. Please repeat your query. | |
56 | <NickServ> Unknown command UNKNOWN. | |
57 | <MyBot> Unknown command unknown. Please repeat your query. | |
58 | <NickServ> Unknown command UNKNOWN. | |
59 | <MyBot> Unknown command unknown. Please repeat your query. | |
60 | ... | |
61 | ||
62 | Do you understand, what problem may conclude due to PRIVMSG? RFC says | |
63 | clearly, that clients shall not generate automatic replies to NOTICES. | |
64 | That way, your bot would not "talk" to NickServ after a NOTICE anymore. | |
65 | ||
66 | To your case. | |
67 | The most easy implementation of this is creating a NF_USE_PRIVMSG flag, | |
68 | with a value far greater than any of the built-in, so that in future | |
69 | this flag does not collide with any of the original flags. | |
70 | ||
71 | Then you create the new SET command for this, as well as its help text, | |
72 | primarily in the english language file. That part of the work is | |
73 | trivial. | |
74 | ||
75 | Afterwards, you should modify notice_lang, and check for the | |
76 | NF_USE_PRIVMSG flag of the "ngi" being used; and if true, send PRIVMSG | |
77 | instead. The same for notice_help. And your case could be marked as | |
78 | closed. | |
79 | ||
80 | Do keep in mind that requesting support for modified services versions | |
81 | are subject to be ignored. | |
82 | ||
83 | I hope it helps, | |
84 | yusuf | |
85 | ||
86 | On Thu, 2003-09-04 at 05:49, Brent DiNicola wrote: | |
87 | ><i> It wasn't an easy subject to sum up in just a few words. | |
88 | </I>><i> | |
89 | </I>><i> I am wanting to do something to the ircservices code, I want to change | |
90 | </I>><i> the way the notice() works. I know that modifying the send.c would be | |
91 | </I>><i> very frowned upon and then I got to thinking and had suggested that I | |
92 | </I>><i> maybe make a module to keep the information for me. I know it's against | |
93 | </I>><i> the RFC, but I am pressed against a brick wall here, I have to give the users | |
94 | </I>><i> an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE | |
95 | </I>><i> I would like to give them the option of turning on PRIVMSG but have NOTICE | |
96 | </I>><i> be the default, that would get the lazy people to use NOTICE. Eventually | |
97 | </I>><i> getting rid of this problem. In the mean time, I was thinking what is the best | |
98 | </I>><i> way to go about this without causing trouble for me and anyone else who has | |
99 | </I>><i> to deal with this code. Is it possible or even suggested to make a module that | |
100 | </I>><i> would replace the notice() from send.c with it's own, leaving the code in | |
101 | </I>><i> send.c | |
102 | </I>><i> alone and not causing troubles down the road. Suggestions were that I make a | |
103 | </I>><i> module that kept the info for each nick's setting and then if I could override | |
104 | </I>><i> the notice() and notice_lang() and notice_help() in send.c that would keep | |
105 | </I>><i> all the | |
106 | </I>><i> other code clean and not cause other troubles. I want to know what the best | |
107 | </I>><i> way to do this would be, I know it's against RFC but I want to move to newer | |
108 | </I>><i> services than the 1.4.3pre4 that we are using now and add modules so that I | |
109 | </I>><i> can do things down the line. They are used to having PRIVMSG and I can't just | |
110 | </I>><i> change it without running people off, so if I can make PRIVMSG an option | |
111 | </I>><i> then I can't be blamed if they are lazy. Opinions on how to go about this? I | |
112 | </I>><i> know this topic has been asked before and I know your not going to make it | |
113 | </I>><i> part of your code, I just wanted to know from the people who know the code | |
114 | </I>><i> really well what the best route to take would be to do the least amount of | |
115 | </I>><i> damage. (And if someone has done this.. please let me know what you did, | |
116 | </I>><i> examples would rock) | |
117 | </I>><i> | |
118 | </I>><i> Thanks | |
119 | </I>><i> | |
120 | </I>><i> Brent | |
121 | </I>><i> | |
122 | </I>><i> | |
123 | </I>><i> | |
124 | </I>><i> ---------------------------------------------------------- | |
125 | </I>><i> | Brent DiNicola | | |
126 | </I>><i> | The Whitewolf of Immyrr | | |
127 | </I>><i> | <<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">elric at elric.net</A>> | | |
128 | </I>><i> | <A HREF="http://www.melnibone.net">http://www.melnibone.net</A> | | |
129 | </I>><i> | Disclaimer: Any opinions expressed here are | | |
130 | </I>><i> | from my dog. Any liabilities fall to the dog. | | |
131 | </I>><i> ----------------------------------------------------------- | |
132 | </I>><i> | |
133 | </I>><i> ------------------------------------------------------------------ | |
134 | </I>><i> To unsubscribe or change your subscription options, visit: | |
135 | </I>><i> <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding</A> | |
136 | </I>-- | |
137 | ------------------------------------------------------------------ | |
138 | |<i> Yusuf Iskenderoglu | You get to meet all sorts, | | |
139 | </I>|<i> eMail - <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">uhc0 at stud.uni-karlsruhe.de</A>| in this line of work... | | |
140 | </I>|<i> eMail - <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">s_iskend at ira.uka.de</A> | | | |
141 | </I>|<i> ICQ UIN : 20587464 \ TimeMr14C | | | |
142 | </I>------------------------------------------------------------------ | |
143 | ||
144 | ||
145 | </PRE> | |
146 | ||
147 | <!--endarticle--> | |
148 | <HR> | |
149 | <P><UL> | |
150 | <!--threads--> | |
151 | <LI>Previous message: <A HREF="002200.html">[IRCServices Coding] Which route to take - Module? | |
152 | </A></li> | |
153 | <LI>Next message: <A HREF="002203.html">[IRCServices Coding] Which route to take - Module? | |
154 | </A></li> | |
155 | <LI> <B>Messages sorted by:</B> | |
156 | <a href="date.html#2756">[ date ]</a> | |
157 | <a href="thread.html#2756">[ thread ]</a> | |
158 | <a href="subject.html#2756">[ subject ]</a> | |
159 | <a href="author.html#2756">[ author ]</a> | |
160 | </LI> | |
161 | </UL> | |
162 | ||
163 | </body></html> |