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
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
irccdctl will come back to a plain line based UTF-8
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.
irccdctl commands will be kept as-is without
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.