[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 

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:


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,