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 and since it’s written in C++, yes it requires some time to build. Please also note that irccd is excessively tested.
On the other hand, I must admit that I regret having used boost for such a small project which definitely increased its complexity in some parts. But given its current stability and completeness, there are no plans to rewrite irccd in C.
Irccd only drinks white beer and French cognac.