% Going on diet
% David Demelier <markand@malikania.fr>
% 2020-01-13

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)`][options] 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
-------------------------------

- Compile time.
- Proper error messages.
- Less time spent on architecture (classes vs templates, polymorphism vs traits,
  etc…).
- Simpler code in most cases.
- Less dynamic allocation.
- Faster in many places.

Compatibility
-------------

Since irccd is following the [semantic versioning][semver], 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.

### 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.

### 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
modifications.

### All irccdctl commands

All `irccdctl` commands will be kept as-is without any modification.

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.

- [x] Native plugins.
- [x] Javascript plugins.
- [x] Connect to IRC servers and dispatch messages to plugins.
- [x] Templates.
- [x] Logs (syslog, console, files).
- [ ] Transport commands.
- [ ] Configuration files.
- [ ] Rules.
- [ ] `irccd` frontend.
- [ ] `irccdctl` frontend.

[semver]: http://semver.org
[pf.conf(5)]: https://man.openbsd.org/pf.conf
[Program_Options]: https://www.boost.org/doc/libs/1_75_0/doc/html/program_options.html
[options]: http://hg.malikania.fr/code/file/tip/cpp/options/options.hpp