31
|
1 % irccd - faq |
|
2 % David Demelier <markand@malikania.fr> |
43
|
3 % 2022-02-03 |
31
|
4 |
|
5 Frequently asked questions |
|
6 ========================== |
|
7 |
|
8 Is SSL supported? |
|
9 ----------------- |
|
10 |
|
11 Yes. |
|
12 |
|
13 Why plugins are not loaded per server? |
|
14 -------------------------------------- |
|
15 |
|
16 This is a good question. |
|
17 |
|
18 I thought a lot about using plugin per server at first, this will add more |
|
19 flexibility about using different plugin configuration per server but will also |
|
20 be a huge pain to maintain for the user. Because a lot of people will use an |
|
21 only one irccd instance and server, I prefer to keep plugins globally and not |
|
22 per server basis. |
|
23 |
|
24 This also means that by default, all plugins will be enabled on all servers and |
|
25 channels but it can be easily filtered with the irccd rule system. |
|
26 |
|
27 Example: |
|
28 |
|
29 # Create a whitelist for plugin 'xyz'. |
|
30 [rule] |
|
31 plugins = xyz |
|
32 action = drop |
|
33 |
|
34 # Re-enable 'xyz' on desired channels. |
|
35 [rule] |
|
36 servers = "myserver" |
|
37 channels = "#mychannel" |
|
38 plugins = xyz |
|
39 action = accept |
|
40 |
|
41 Why Javascript instead of (insert my favorite language here)? |
|
42 ------------------------------------------------------------- |
|
43 |
|
44 Because Javascript is a very light language easy to embed. The irccd |
|
45 implementation uses [duktape](http://duktape.org). |
|
46 |
|
47 - Starting with version 3.0.0 you can write plugins in C++. |
|
48 - Starting with version 3.1.0 you can write hooks in any language, but they are |
|
49 less powerful than plugins though. |
|
50 |
|
51 See also question below. |
|
52 |
|
53 Do you plan to add (my language)? |
|
54 --------------------------------- |
|
55 |
|
56 No, there are plenty of bots which support your language. |
|
57 |
|
58 Is it possible to combine commands like `!foo !bar`? |
|
59 ---------------------------------------------------- |
|
60 |
|
61 Absolutely no, and will never. The special `onCommand` event is dedicated to |
|
62 specific plugin. |
|
63 |
|
64 Internally, when a user writes a message like `!stats hello` (assuming that |
|
65 command char is '!'), then irccd will search for the plugin *stats* and pass the |
|
66 trailing text to the plugin command. |
|
67 |
|
68 In that way, the plugins will never conflict on `onCommand`. This security is |
|
69 called plugin namespaces. By the way, this does not make sense and I don't know |
|
70 many bot which support this "feature". |
|
71 |
|
72 Remember, IRC plugins are not shell commands that you can pipe one to another. |
|
73 |
|
74 Is it possible to integrate plugin dependencies? |
|
75 ------------------------------------------------ |
|
76 |
|
77 No, plugins should be independant. |
|
78 |
|
79 There are no ways to require a plugin. However, you can still verify if a plugin |
|
80 is loaded via the `Irccd.Plugin.info` function and eventually load it using |
|
81 `Irccd.Plugin.load` |
|
82 |
|
83 Does irccd support DCC? |
|
84 ----------------------- |
|
85 |
43
|
86 Nobody use DCC. |
31
|
87 |
|
88 What if I use a specific encoding? |
|
89 ---------------------------------- |
|
90 |
|
91 Irccd is encoding agnostic just as the IRC protocol. If the server send UTF-8 |
|
92 messages, then irccd will pass these UTF-8 encoded messages to the plugins. |
|
93 |
|
94 The bot does not connect to the Freenode server! |
|
95 ------------------------------------------------ |
|
96 |
|
97 Be sure to set a different identity (with different nickname **and** username) |
|
98 because **irccd** is a registered nickname. |
|
99 |
|
100 Isn't irccd bloat and against KISS/UNIX philosophies? |
|
101 ----------------------------------------------------- |
|
102 |
|
103 The definition of bloat is quite subjective. |
|
104 |
|
105 In some aspects it may be considered as a bit too complicated for an IRC bot but |
|
106 is still quite minimal. |
|
107 |
43
|
108 Because irccd offers a runtime controllable mechanism with lots of commands (32 |
38
|
109 at this time of writing), it increases the total number of lines of code. Please |
|
110 also note that irccd is excessively tested. We could argue that a lots of these |
|
111 command may be unneeded but I like that I can keep the daemon running for months |
|
112 without having to shut it down and restart it to change its nickname. |
|
113 |
|
114 The Javascript glue code also requires more than the half of the code base to |
|
115 bind the C code to the Javascript interpreter. Disabling Javascript reduces the |
|
116 total code by more than 60%. |
31
|
117 |
38
|
118 But in other hand, irccd still follows the UNIX philosophy of doing minimal |
|
119 things and be extended by the user externally through plugins. It also tries to |
|
120 stick to POSIX and use as much as possible simple and clean code. By itself, |
|
121 irccd's responsability is to poll IRC events, call plugins and hooks and that's |
|
122 it. |
|
123 |
|
124 Shouldn't irccdctl be named irccctl? |
|
125 ------------------------------------ |
|
126 |
|
127 Yes, technically speaking UNIX daemons may have a name `bard` and an optional |
|
128 utility `barctl` without the trailing 'd' to control the daemon. But since irccd |
43
|
129 has already two 'c', irccctl would be annoying to type especially since having |
38
|
130 three identical consecutive letter is unusual. So as an exception, the utility |
|
131 is named `irccdctl` rather than `irccctl`. |
31
|
132 |
|
133 What does irccd drink? |
|
134 ---------------------- |
|
135 |
|
136 Irccd only drinks white beer and French cognac. |
|
137 |
|
138 [duktape]: http://duktape.org |