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 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).
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.
Today I’m very glad announce that I’m rewriting irccd in pure POSIX/C for the version 4.0.0.
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.
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.
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 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.
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.
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.
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.
Almost all irccdctl
commands will be kept as-is without
any modification.
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.
irccd
frontend.irccdctl
frontend.links
rewrite (was a native C++ plugin).