[IRCServices Coding] send_cmd in non-protocol modules
Craig Edwards
brain at winbot.co.uk
Sat May 7 14:04:16 PDT 2005
Hi everyone
As an ircd developer ive noticed an annoying issue with ircservices.
IRCServices 5 is a powerful technologically superior program, but, it
has one tiny flaw which i will detail here (it isnt too difficult to fix
actually):
IRCServices 5 has protocol modules which allow it to connect to many
different kinds of ircds easily. Great idea. However, the core blatantly
uses send_cmd, and makes assumptions about the format of specific
commands, which in parts, makes protocol modules practically useless.
Lets take for example two ircds, one very common and very well known,
ircu, and one not so common and not so well known, inspircd. Both of
these ircds use non-standard server to server communication, which is
tokenized by default and *cannot* be sent untokenized. IRCServices, when
sending a notice, has a send_cmd in send.c, which does this:
send_cmd(source, "NOTICE %s :%s", dest, buf);
This is fine for ircds which follow RFC1459 to the letter, but as we all
know, many (read most) ircds do not. This means, that unless an ircd
supports the RFC *to the letter*, ircservices cannot support it, without
some major kludges (e.g. rewriting input strings). If you send this
command to IRCu, using the P10 protocol, IRCu will disconnect your
services server for sending invalid commands (IRCu once authenticated
has no idea what NOTICE is, only the *token* for NOTICE). InspIRCd will
simply drop the command. I'm sure there are other ircds out there that
will have similar problems.
There are many other commands which are 'assumed' in this manner in the
core, some being:
PRIVMSG, SVSMODE, SVS2MODE, PING, PONG, VERSION
In my own IRCd ive managed to kludge around this by having the uplink
rewrite said messages to valid tokens before theyre processed, but IRCu
and other token-only ircds are not able to do this.
Now, this email is *not a flame or a rant*, i love ircservices, and i
would love to see this situation improved. If i must submit patches to
andy myself to do so, i will (i have the spare time to do it) but here
is what i suggest, wether its me or someone else that codes it:
These functions (notice, privmsg, mode, ping etc) should be moved into
the protocol modules, e.g. move the notice() function to the protocol
module, move the svsmode() function to the protocol module, etc. This is
the way other services packages (such as anope) do it. Right now, there
is something you can do (which is kludgy) which allows you to 'override'
the default functions in the core, but if you use this kludge, you
cannot compile ircservices statically (which probably isnt good).
So, theres my issue, and my recommended way of fixing it :-)
Thanks for reading all this, and please let me know what you think,
Brain