This is a good question.
I thought a lot about using plugin per server at first, this will add more flexibility about using different plugin configuration per server but will also be a huge pain to maintain for the user. Because a lot of people will use an only one irccd instance and server, I prefer to keep plugins globally and not per server basis.
This also means that by default, all plugins will be enabled on all servers and channels but it can be easily filtered with the irccd rule system.
# Create a whitelist for plugin 'xyz'. [rule] plugins = xyz action = drop # Re-enable 'xyz' on desired channels. [rule] servers = "myserver" channels = "#mychannel" plugins = xyz action = accept
See also question below.
No, there are plenty of bots which support your language.
Absolutely no, and will never. The special
onCommand event is dedicated to specific plugin.
Internally, when a user writes a message like
!stats hello (assuming that command char is ‘!’), then irccd will search for the plugin stats and pass the trailing text to the plugin command.
In that way, the plugins will never conflict on
onCommand. This security is called plugin namespaces. By the way, this does not make sense and I don’t know many bot which support this “feature”.
Remember, IRC plugins are not shell commands that you can pipe one to another.
No, plugins should be independant.
There are no ways to require a plugin. However, you can still verify if a plugin is loaded via the
Irccd.Plugin.info function and eventually load it using
Not at the moment.
Irccd is encoding agnostic just as the IRC protocol. If the server send UTF-8 messages, then irccd will pass these UTF-8 encoded messages to the plugins.
Be sure to set a different identity (with different nickname and username) because irccd is a registered nickname.
The definition of bloat is quite subjective.
In some aspects it may be considered as a bit too complicated for an IRC bot but is still quite minimal.
Because irccd offers a runtime controllable mechanism with lots of commands (30 at this time of writing), it increases the total number of lines of code. Please also note that irccd is excessively tested. We could argue that a lots of these command may be unneeded but I like that I can keep the daemon running for months without having to shut it down and restart it to change its nickname.
But in other hand, irccd still follows the UNIX philosophy of doing minimal things and be extended by the user externally through plugins. It also tries to stick to POSIX and use as much as possible simple and clean code. By itself, irccd’s responsability is to poll IRC events, call plugins and hooks and that’s it.
Yes, technically speaking UNIX daemons may have a name
bard and an optional utility
barctl without the trailing ‘d’ to control the daemon. But since irccd has already two ‘c’ irccctl would be annoying to type especially since having three identical consecutive letter is unusual. So as an exception, the utility is named
irccdctl rather than
Irccd only drinks white beer and French cognac.