38
|
1 % Going on diet |
|
2 % David Demelier <markand@malikania.fr> |
|
3 % 2021-01-13 |
|
4 |
|
5 Irccd is going on diet |
|
6 ====================== |
|
7 |
|
8 Since my original irccd implementation in mostly pure C++11 in 2013, I was |
|
9 pretty happy with the result. It was small, lightweight with a clean code base. |
|
10 At this time it was also using Lua instead of Javascript but after several |
|
11 headaches maintaining support for every Lua version that break compatibility I |
|
12 was suggested (by a Lua user!) to use Duktape if I like Javascript. |
|
13 |
|
14 Anyway, for the version 2.0.0 I've started adding more features and splitting |
|
15 the code a lot. It was still fine but I faced several issues with my own code, |
|
16 especially in the timer and portable sockets selector (epoll, kqueue, poll) and |
|
17 so I decided to move to Boost for the 3.0.0 version. |
|
18 |
|
19 This was my main regret. |
|
20 |
|
21 Boost |
|
22 ===== |
|
23 |
|
24 Boost is a indeed quality framework that is stable and proven. But it's bloat |
|
25 and terribly complex. The code base grown a lot to add generic support and |
|
26 required to use templates all over the place. I was quite disappointed about the |
|
27 status of the code no matter portable it was. The module [Program_Options][] is |
|
28 also total nonsense of complexity to parse simple options. I finally ended up |
|
29 writing my own portable [`getopt(3)`][options] in 69 lines of code. |
|
30 |
|
31 The build process also evolved in the wrong way, it now requires more than five |
|
32 minutes to build the entire project even though it only consists of roughly |
|
33 19000 lines of code (unicode support adds by itself 5000 lines of pure data). |
|
34 |
|
35 C++20 and beyond |
|
36 ================ |
|
37 |
|
38 When I first started learning C++11 I was really loving the new functionalities |
|
39 and would honestly not switch to it (from C) if it wasn't there. It's safer, |
|
40 more robust and cleaner in several aspects. |
|
41 |
|
42 But as a guy who needs to updates itself when there are new revisions, I've |
|
43 upgraded irccd to newer C++ versions each time they were broadly supported. And |
|
44 since C++20 I started scratching my head about the language complexity. |
|
45 Concepts, modules, ranges. All syntax are weird and unwelcoming, I personally |
|
46 think this language becomes more and more elitist. |
|
47 |
|
48 Future of irccd 4.0.0 |
|
49 ===================== |
|
50 |
|
51 Today I'm very glad announce that I'm rewriting irccd in pure POSIX/C for the |
|
52 version 4.0.0. |
|
53 |
|
54 What's definitely better with C |
|
55 ------------------------------- |
|
56 |
|
57 - Compile time. |
|
58 - Proper error messages. |
|
59 - Less time spent on architecture (classes vs templates, polymorphism vs traits, |
|
60 etc…). |
|
61 - Simpler code in most cases. |
|
62 - Less dynamic allocation. |
|
63 - Faster in many places. |
|
64 |
|
65 Compatibility |
|
66 ------------- |
|
67 |
|
68 Since irccd is following the [semantic versioning][semver], the 4.0.0 branch is |
|
69 allowed to do major breaking changes. But don't run away no many breaking |
|
70 changes will happen. |
|
71 |
|
72 What will change |
|
73 ---------------- |
|
74 |
|
75 ### irccd.conf and irccdctl.conf files |
|
76 |
|
77 Both tools were using a custom crafted .ini file format. In various places it |
|
78 was quite unconvenient to use. For example configuring plugins require to write |
|
79 different sections such as: |
|
80 |
|
81 [plugins] |
|
82 hangman = |
|
83 |
|
84 [plugin.hangman] |
|
85 collaborative = false |
|
86 |
|
87 [templates.hangman] |
|
88 win = "congratulations!" |
|
89 |
|
90 Instead, the new files will be parsed using a custom DSL based on lex/yacc which |
|
91 have the benefit of being part of POSIX. The format isn't finalized yet but I |
|
92 can promise that it will look much better with some influences from the |
|
93 venerable [pf.conf(5)][] file from OpenBSD. |
|
94 |
|
95 ### Networking protocol |
|
96 |
|
97 To stay simpler, the network messages between `irccd` and `irccdctl` will come |
|
98 back to a plain line based UTF-8 messages. |
|
99 |
|
100 Example: |
|
101 |
|
102 MESSAGE freenode #botwar oh hi! |
|
103 TOPIC freenode #botwar this is my new topic. |
|
104 |
|
105 Error messages will be written in human format and no longer provide specific |
|
106 error code either. |
|
107 |
|
108 ### Windows support will be forwarded to second class citizen |
|
109 |
|
110 Windows isn't a platform I personally like because Microsoft is a company that |
|
111 does not cooperate in portability. Writing POSIX software in Windows is a total |
|
112 nightmare unless you run cygwin which is also annoying. |
|
113 |
|
114 Portability code will be added as much as possible as long as they don't pollute |
|
115 the code. |
|
116 |
|
117 ### Native API |
|
118 |
|
119 Obviously by switching from C++ to C, the C++ API becomes totally obsolescent. |
|
120 The new exposed C API will be much simpler and less featureful than the previous |
|
121 C++ one. This is because I think exposed API must only be related to irccd and |
|
122 internal stuff must be kept as that. |
|
123 |
|
124 Also, the documentation of the exposed C API will be provided in manual pages |
|
125 only as doxygen has a poor interface. As always, manual pages will be available |
|
126 online as well too. |
|
127 |
|
128 ### Unix transport only |
|
129 |
|
130 For simplicity reasons, the only transport supported will be based on UNIX |
|
131 domain sockets without SSL, without password. Instead users are encouraged to |
|
132 set permissions on the socket instead. |
|
133 |
|
134 This also reduce the code complexity a lot. |
|
135 |
|
136 What will be kept |
|
137 ----------------- |
|
138 |
|
139 ### The Javascript API |
|
140 |
|
141 Now you can breathe. The Javascript for the most part will be kept untouched |
|
142 with a few minor adjustments but your plugins should work without any |
|
143 modifications. |
|
144 |
|
145 ### All irccdctl commands |
|
146 |
|
147 All `irccdctl` commands will be kept as-is without any modification. |
|
148 |
|
149 Questions and answers |
|
150 ===================== |
|
151 |
|
152 Q: Why a bot in C? There are already ones! |
|
153 : Yes, but no one uses Javascript as extending language and no one supports |
|
154 rules and templates like irccd. |
|
155 |
|
156 Q: Is it a rewrite from scratch? |
|
157 : No. Lot of code was simply converted from C++ to C by adapting some code |
|
158 logic. The javascript being based on the C Duktape library did not need lots |
|
159 of modifications. From scratch code is mostly: new transports, logs and |
|
160 irccd main object. |
|
161 |
|
162 Q: Which C standard will it be written? |
|
163 : Mostly C99 with few bits from C11 like atomics and noreturn. |
|
164 |
|
165 Estimated time of arrival |
|
166 ========================= |
|
167 |
|
168 For now, the irccd 4 rewrite is on heavy progress and starts to be usable. It |
|
169 will be probably released during fall 2021. |
|
170 |
|
171 Please come back to see the advancement on this page. |
|
172 |
|
173 - [x] Native plugins. |
|
174 - [x] Javascript plugins. |
|
175 - [x] Connect to IRC servers and dispatch messages to plugins. |
|
176 - [x] Templates. |
|
177 - [x] Logs (syslog, console, files). |
|
178 - [x] Transport commands (almost complete). |
|
179 - [x] Configuration files. |
|
180 - [x] Rules. |
|
181 - [x] `irccd` frontend. |
|
182 - [x] `irccdctl` frontend. |
|
183 - [ ] Excessive testing. |
|
184 - [x] Plugin `links` rewrite (was a native C++ plugin). |
|
185 - [x] New Irccd.Rule API. |
|
186 - [x] New Irccd.Hook API. |
|
187 - [x] Hooks. |
|
188 |
|
189 [semver]: http://semver.org |
|
190 [pf.conf(5)]: https://man.openbsd.org/pf.conf |
|
191 [Program_Options]: https://www.boost.org/doc/libs/1_75_0/doc/html/program_options.html |
|
192 [options]: http://hg.malikania.fr/code/file/tip/cpp/options/options.hpp |