Irccd is going on diet

Since my original irccd implementation in mostly pure C++11 in 2013, I was pretty happy with the result. It was small, lightweight with a clean code base. At this time it was also using Lua instead of Javascript but after several headaches maintaining support for every Lua version that break compatibility I was suggested (by a Lua user!) to use Duktape if I like Javascript.

Anyway, for the version 2.0.0 I’ve started adding more features and splitting the code a lot. It was still fine but I faced several issues with my own code, especially in the timer and portable sockets selector (epoll, kqueue, poll) and so I decided to move to Boost for the 3.0.0 version.

This was my main regret.

Boost

Boost is a indeed quality framework that is stable and proven. But it’s bloat and terribly complex. The code base grown a lot to add generic support and required to use templates all over the place. I was quite disappointed about the status of the code no matter portable it was. The module Program_Options is also total nonsense of complexity to parse simple options. I finally ended up writing my own portable getopt(3) in 69 lines of code.

The build process also evolved in the wrong way, it now requires more than five minutes to build the entire project even though it only consists of roughly 19000 lines of code (unicode support adds by itself 5000 lines of pure data).

C++20 and beyond

When I first started learning C++11 I was really loving the new functionalities and would honestly not switch to it (from C) if it wasn’t there. It’s safer, more robust and cleaner in several aspects.

But as a guy who needs to updates itself when there are new revisions, I’ve upgraded irccd to newer C++ versions each time they were broadly supported. And since C++20 I started scratching my head about the language complexity. Concepts, modules, ranges. All syntax are weird and unwelcoming, I personally think this language becomes more and more elitist.

Future of irccd 4.0.0

Today I’m very glad announce that I’m rewriting irccd in pure POSIX/C for the version 4.0.0.

What’s definitely better with C

Compatibility

Since irccd is following the semantic versioning, the 4.0.0 branch is allowed to do major breaking changes. But don’t run away no many breaking changes will happen.

What will change

irccd.conf and irccdctl.conf files

Both tools were using a custom crafted .ini file format. In various places it was quite unconvenient to use. For example configuring plugins require to write different sections such as:

[plugins]
hangman =

[plugin.hangman]
collaborative = false

[templates.hangman]
win = "congratulations!"

Instead, the new files will be parsed using a custom DSL based on lex/yacc which have the benefit of being part of POSIX. The format isn’t finalized yet but I can promise that it will look much better with some influences from the venerable pf.conf(5) file from OpenBSD.

Networking protocol

To stay simpler, the network messages between irccd and irccdctl will come back to a plain line based UTF-8 messages.

Example:

MESSAGE freenode #botwar oh hi!
TOPIC freenode #botwar this is my new topic.

Error messages will be written in human format and no longer provide specific error code either.

Windows support will be forwarded to second class citizen

Windows isn’t a platform I personally like because Microsoft is a company that does not cooperate in portability. Writing POSIX software in Windows is a total nightmare unless you run cygwin which is also annoying.

Portability code will be added as much as possible as long as they don’t pollute the code.

Native API

Obviously by switching from C++ to C, the C++ API becomes totally obsolescent. The new exposed C API will be much simpler and less featureful than the previous C++ one. This is because I think exposed API must only be related to irccd and internal stuff must be kept as that.

Also, the documentation of the exposed C API will be provided in manual pages only as doxygen has a poor interface. As always, manual pages will be available online as well too.

Unix transport only

For simplicity reasons, the only transport supported will be based on UNIX domain sockets without SSL, without password. Instead users are encouraged to set permissions on the socket instead.

This also reduce the code complexity a lot.

What will be kept

The Javascript API

Now you can breathe. The Javascript for the most part will be kept untouched with a few minor adjustments but your plugins should work without any or few modifications.

About irccdctl commands

Almost all irccdctl commands will be kept as-is without any modification.

Questions and answers

Q: Why a bot in C? There are already ones!
Yes, but no one uses Javascript as extending language and no one supports rules and templates like irccd.
Q: Is it a rewrite from scratch?
No. Lot of code was simply converted from C++ to C by adapting some code logic. The javascript being based on the C Duktape library did not need lots of modifications. From scratch code is mostly: new transports, logs and irccd main object.
Q: Which C standard will it be written?
Mostly C99 with few bits from C11 like atomics and noreturn.

Estimated time of arrival

For now, the irccd 4 rewrite is on heavy progress and starts to be usable. It will be probably released during fall 2021.

Please come back to see the advancement on this page.