add news/2020-01-13.diet

Wed, 13 Jan 2021 22:12:21 +0100

author
David Demelier <markand@malikania.fr>
date
Wed, 13 Jan 2021 22:12:21 +0100
changeset 35
a584aa4fa8f4
parent 34
394a5ae718bb
child 36
a0634dddff43

add news/2020-01-13.diet

Makefile file | annotate | diff | comparison | revisions
css/no-class.css file | annotate | diff | comparison | revisions
index.md file | annotate | diff | comparison | revisions
news/2020-01-13.diet.md file | annotate | diff | comparison | revisions
--- a/Makefile	Mon Jan 04 10:43:08 2021 +0100
+++ b/Makefile	Wed Jan 13 22:12:21 2021 +0100
@@ -55,7 +55,8 @@
                 downloads.md \
                 faq.md \
                 index.md \
-                versioning.md
+                versioning.md \
+                news/2020-01-13.diet.md
 SITE_HTML=      ${SITE_SRCS:.md=.html}
 
 .SUFFIXES:
--- a/css/no-class.css	Mon Jan 04 10:43:08 2021 +0100
+++ b/css/no-class.css	Wed Jan 13 22:12:21 2021 +0100
@@ -450,7 +450,6 @@
 }
 input,
 textarea {
-  width: 100%;
   margin-bottom: 1em;
   padding: .25em .5em;
   border: 1px solid #ddd;
--- a/index.md	Mon Jan 04 10:43:08 2021 +0100
+++ b/index.md	Wed Jan 13 22:12:21 2021 +0100
@@ -24,6 +24,7 @@
 News
 ----
 
+- (2021-01-13) Irccd is going on a diet. [More…](2020-01-13.diet.html)
 - (2021-01-04) Bugfix release: irccd 3.1.1,
 - (2020-07-03) Minor release: irccd 3.1.0,
 - (2019-10-06) Bugfix release: irccd 3.0.3,
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/news/2020-01-13.diet.md	Wed Jan 13 22:12:21 2021 +0100
@@ -0,0 +1,164 @@
+% 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

mercurial