]> jfr.im git - irc/quakenet/snircd.git/blame - doc/api/modebuf.txt
sync undernet upstream ircu changes.
[irc/quakenet/snircd.git] / doc / api / modebuf.txt
CommitLineData
189935b1 1Generating and parsing channel mode strings is often a very
2complicated process. The ModeBuf interface, along with the associated
3mode parsing functions, attempt to make this much more programmatic.
4The interface to the functions in this suite is itself very
5complicated, unfortunately, though most of the complication is in the
6effects of various flags on the operation of the functions.
7
8<struct>
9struct ModeBuf;
10
11This structure is used to accumulate and describe several mode
12changes. None of its fields are directly or indirectly accessible to
13the application; a struct ModeBuf is only suitable for passing to the
14modebuf_*() suite of functions. ModeBuf structures must be allocated
15by the caller.
16</struct>
17
18<function>
19void modebuf_init(struct ModeBuf *mbuf, struct Client *source,
20 struct Client *connect, struct Channel *chan,
21 unsigned int dest);
22
23This function initializes a caller-allocated ModeBuf, _mbuf_, with the
24given parameters. If the mode should not be sent to a particular
25server, perhaps because it was received from that server, that server
26should be specified by the _connect_ parameter. The channel the mode
27change will take place on is given by the _chan_ parameter, and the
28disposition of the mode is given by the _dest_ parameter, which is the
29binary OR of the MODEBUF_DEST_* flags described below.
30</function>
31
32<macro>
33#define MODEBUF_DEST_CHANNEL 0x0001 /* Mode is flushed to channel */
34
35This flag, when set in a call to modebuf_init(), causes the accumulated
36mode change to be sent to the channel (in client<->server protocol, of
37course).
38</macro>
39
40<macro>
41#define MODEBUF_DEST_SERVER 0x0002 /* Mode is flushed to server */
42
43If other servers should be made aware of the mode change, this flag
44should be passed to modebuf_init(). One time when the mode change may
45not be passed is when processing the mode in a BURST message.
46</macro>
47
48<macro>
49#define MODEBUF_DEST_OPMODE 0x0100 /* Send server mode as OPMODE */
50
51This flag is used to tell the modebuf_*() suite to send an OPMODE
52message to other servers, rather than an ordinary MODE message.
53</macro>
54
55<macro>
56#define MODEBUF_DEST_DEOP 0x0200 /* Deop the offender */
57
58When bouncing a mode change, giving this flag to modebuf_init() causes
59the originating user to be deopped on the channel as part of the mode
60bounce.
61</macro>
62
63<macro>
64#define MODEBUF_DEST_BOUNCE 0x0400 /* Bounce the modes */
65
66When a mode change is illegitimate, that is, when it originates from a
67user that is not (as far as this server knows) a channel operator, the
68mode change should be bounced. This involves reversing the sense of
69the mode and sending it back to the originating server. This flag is
70used to tell the modebuf_*() suite to do just that.
71</macro>
72
73<macro>
74#define MODEBUF_DEST_LOG 0x0800 /* Log the mode changes to OPATH */
75
76The OPMODE command is reserved for IRC operators. When it is used,
77the server should log the command for accountability purposes. This
78flag, given to modebuf_init(), will cause the ModeBuf system to log
79the exact mode change to a log file.
80</macro>
81
82<macro>
83#define MODEBUF_DEST_HACK2 0x2000 /* Send a HACK(2) notice, reverse */
84
85When a remote user that this server does not think is a channel
86operator proceeds to change a channel mode, that mode must be
87bounced. In addition, in order to provide some debugging capability,
88a server notice may be sent, called a "HACK(2)" notice. Passing
89modebuf_init() this flag causes that notice to be sent.
90</macro>
91
92<macro>
93#define MODEBUF_DEST_HACK3 0x4000 /* Send a HACK(3) notice, TS == 0 */
94
95When the origin of a mode change is a server, we should always accept
96the mode change. To provide accountability, however, a server notice
97should be sent. This flag will cause the server to generate a
98"HACK(3)" notice.
99</macro>
100
101<macro>
102#define MODEBUF_DEST_HACK4 0x8000 /* Send a HACK(4) notice, TS == 0 */
103
104Some servers are special. When a server that has a Uworld entry
105issues a mode change, we send a "HACK(4)" message to differentiate it
106from an ordinary server changing a channel mode. This is the flag
107that must be passed to modebuf_init() to cause that behavior.
108</macro>
109
110<function>
111void modebuf_mode(struct ModeBuf *mbuf, unsigned int mode);
112
113Certain channel modes take no arguments. Those mode changes can be
114fed to the ModeBuf system using modebuf_mode(). The _mode_ parameter
115is a bit mask of the mode changes, and must have one of MODE_ADD or
116MODE_DEL set.
117</function>
118
119<function>
120void modebuf_mode_uint(struct ModeBuf *mbuf, unsigned int mode,
121 unsigned int uint);
122
123One channel mode, the "limit" mode ("+l"), takes a single integer
124argument. This limit can be fed to the ModeBuf system with the
125modebuf_mode_uint() function. The _mode_ parameter must be the binary
126OR of one of MODE_ADD or MODE_DEL with the MODE_LIMIT flag. The
127_uint_ parameter specifies the limit.
128</function>
129
130<function>
131void modebuf_mode_string(struct ModeBuf *mbuf, unsigned int mode,
132 char *string, int free);
133
134Some channel modes take a string parameter. These can be fed to
135ModeBuf with modebuf_mode_string(). The _mode_ parameter should be
136the binary OR of one of MODE_ADD or MODE_DEL with the flag for the
137mode. The _string_ parameter specifies the string, and the _free_
138parameter indicates whether the ModeBuf system should call MyFree() on
139the string once it is done with it.
140</function>
141
142<function>
143void modebuf_mode_client(struct ModeBuf *mbuf, unsigned int mode,
144 struct Client *client);
145
146The remaining channel modes take a parameter specifying a client.
147These can be fed to ModeBuf with modebuf_mode_client(). The _mode_
148parameter should be the binary OR of one of MODE_ADD or MODE_DEL with
149the flag for the mode. The _client_ parameter should be a pointer to
150a struct Client specifying which client the mode is supposed to act
151upon.
152</function>
153
154<function>
155int modebuf_flush(struct ModeBuf *mbuf);
156
157This function simply flushes the contents of the struct ModeBuf
158specified by _mbuf_ to the appropriate destinations, as was specified
159by the _dest_ parameter in the call to modebuf_init(). This function
160returns 0 for the convenience of callers that must return an integer.
161</function>
162
163<function>
164void modebuf_extract(struct ModeBuf *mbuf, char *buf);
165
166One use of the ModeBuf within ircd requires the ability to pull a
167simple mode string out of the struct ModeBuf for use elsewhere. This
168can be accomplished with this function. The _buf_ parameter should be
169large enough to accommodate the simple mode string.
170</function>
171
172<function>
173void mode_ban_invalidate(struct Channel *chan);
174
175Looking up bans affecting a particular user can be a fairly expensive
176operation, so the server caches the result of the lookup. Should the
177ban list for a channel change, all the cached results must be
178invalidated to force rechecking. This may be done with the
179mode_ban_invalidate() function, which acts upon the channel given by
180_chan_.
181</function>
182
183<function>
184void mode_invite_clear(struct Channel *chan);
185
186When a channel that was invite-only has the "+i" channel mode removed,
187the invite list that the server keeps is no longer necessary. The
188mode_invite_clear() function flushes that invite list for the channel
189given by _chan_, reclaiming the memory used by the invite list.
190</function>
191
192<function>
193int mode_parse(struct ModeBuf *mbuf, struct Client *cptr, struct Client *sptr,
194 struct Channel *chptr, int parc, char *parv[],
195 unsigned int flags);
196
197This function parses a mode change command, given by the contents of
198_parv[]_, and under the control of _flags_. The channel being modified
199is given by _chptr_, the source of the change is given by _sptr_, and
200the connection the change was received from is given by _cptr_. The
201_parc_ parameter gives the count of the number of elements in the
202_parv[]_ array. The ModeBuf must have already been initialized by a
203call to modebuf_init(), described above. For more information on
204_flags_, see the MODE_PARSE_* macros described below. This function
205returns an integer indicating the number of elements of _parv[]_ it
206used. The modebuf_flush() function must be called upon return from
207mode_parse() to flush the mode changes to the channel.
208</function>
209
210<macro>
211#define MODE_PARSE_SET 0x01 /* actually set channel modes */
212
213When this flag is passed to mode_parse(), the channel mode being
214parsed will actually be effected on the channel.
215</macro>
216
217<macro>
218#define MODE_PARSE_STRICT 0x02 /* +m +n +t style not supported */
219
220Users are permitted to send complicated mode commands like "MODE #foo
221+m +n +t +k foo +i"; servers are not. Passing this flag to
222mode_parse() causes it to strictly enforce this restriction.
223</macro>
224
225<macro>
226#define MODE_PARSE_FORCE 0x04 /* force the mode to be applied */
227
228Some mode changes are not permitted under normal circumstances. When
229this flag is passed to mode_parse(), these mode changes will be
230accepted.
231</macro>
232
233<macro>
234#define MODE_PARSE_BOUNCE 0x08 /* we will be bouncing the modes */
235
236This flag warns mode_parse() that the mode is to be bounced. This
237will cause it to systematically feed each mode into ModeBuf in order
238for that interface to generate the proper bounce messages.
239</macro>
240
241<macro>
242#define MODE_PARSE_NOTOPER 0x10 /* send "not chanop" to user */
243
244This flag is used to warn mode_parse() that the user generating the
245mode change is not a channel operator. If the user attempts to change
246a mode, an appropriate error message will be sent to the user (once).
247</macro>
248
249<macro>
250#define MODE_PARSE_NOTMEMBER 0x20 /* send "not member" to user */
251
252This flag is used to warn mode_parse() that the user generating the
253mode change is not even on the channel. If the user attempts to
254change a mode, an appropriate error message will be sent to the user
255(once).
256</macro>
257
258<macro>
259#define MODE_PARSE_WIPEOUT 0x40 /* wipe out +k and +l during burst */
260
261When this flag is passed to mode_parse(), the channel key and limit
262will be reversed if the mode string doesn't update them. This is used
263for processing BURST messages.
264</macro>
265
266<macro>
267#define MODE_PARSE_BURST 0x80 /* be even more strict w/extra args */
268
269The BURST message is even more strict than a standard MODE message.
270Processing *must* stop after reading the mode string itself, or
271mode_parse() could gobble up arguments not intended for it. This flag
272tells mode_parse() about this restriction.
273</macro>
274
275<authors>
276Kev <klmitch@mit.edu>
277</authors>
278
279<changelog>
280[2001-6-15 Kev] Initial documentation of the ModeBuf and mode parsing
281subsystems.
282</changelog>