mirror of
https://github.com/Mikaela/Limnoria.git
synced 2025-11-04 01:27:21 +01:00
53 lines
2.1 KiB
Plaintext
53 lines
2.1 KiB
Plaintext
Roughly in order of precedence (the closer to the front of the file,
|
|
the more likely it'll be done before next release):
|
|
|
|
* We should have a channel-global value in ircdb.IrcChannel for
|
|
ignoring unregistered users.
|
|
|
|
* It'd be nice to be able to use a backslash to continue lines in the
|
|
registry, so we could linewrap long strings or lists.
|
|
|
|
* We need to store the key for channels in the registry and have an
|
|
easy way for plugins to send joins to channels based on their
|
|
registry configuration.
|
|
|
|
* We need to note when bans expire on a channel and send the unban,
|
|
that way plugins can use the ircdb ban stuff and not worry about
|
|
sending or scheduling unbans.
|
|
|
|
* We should probably add a "hello" command to make things more
|
|
compatible with Eggdrop, since we've been replacing many eggdrop
|
|
bots lately.
|
|
|
|
* We should be able to set the log level for plugins individually.
|
|
|
|
* Rbot has a "remind" plugin that seems pretty cool, we should get
|
|
one as well. It might do well as a command in the Later plugin.
|
|
|
|
* MozBot has a "list" plugin that seems pretty cool, we should get
|
|
one as well.
|
|
|
|
Problems that involve a lot of tedious minutiae, but really need to
|
|
be done at some point:
|
|
|
|
* ircutils.{isChannel,isNick,toLower} should be methods on each Irc
|
|
object, since they can vary per-network. That's not the tedious
|
|
part; the tedious part is having every other place that uses them
|
|
use those methods instead.
|
|
|
|
Hard problems that won't get done until someone really wants to have
|
|
some fun:
|
|
|
|
* Redundant relaying -- having more than one bot handle relaying,
|
|
where a secondary one will automatically take over if the first
|
|
becomes incapacitated.
|
|
|
|
* Have the bot detect when other bots are in the channel responding
|
|
to the same prefix character, and do something based on that.
|
|
|
|
* Unicode support. Basically, we'd have to have a way to set the
|
|
encoding for the server, and use unicode throughout internally.
|
|
The real issue is how much it would affect the current code to
|
|
switch it over to unicode, and what kind of burden it would put on
|
|
plugin authors to deal with that issue.
|