1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices Coding] Which route to take - Module?
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">
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
19 <I>Thu Sep
4 01:
34:
06 PDT
2003</I>
21 <LI>Previous message:
<A HREF=
"002200.html">[IRCServices Coding] Which route to take - Module?
23 <LI>Next message:
<A HREF=
"002203.html">[IRCServices Coding] Which route to take - Module?
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>
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.
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.
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.
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.
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
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
80 Do keep in mind that requesting support for modified services versions
81 are subject to be ignored.
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.
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
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
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)
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> -----------------------------------------------------------
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>
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>------------------------------------------------------------------
151 <LI>Previous message:
<A HREF=
"002200.html">[IRCServices Coding] Which route to take - Module?
153 <LI>Next message:
<A HREF=
"002203.html">[IRCServices Coding] Which route to take - Module?
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>
projects / irc.git / blob