Enhancement: Abstract the event system and friends.

[GoogleCodeExporter]

Currently, most of the event system is hardwired into the bot, using handleLine 
in PircBotX.java. While this is well established and implemented, this forces 
the use of this event system. 

In some cases, this isn't desired, as the Listener model is class based, single 
priority, and has no filtering abilities. (An example, try to make a plugin 
based bot that allows dynamic alias rewriting, full ignoring, and 
rewriting/cancelling output on the fly.)

I propose to abstract the whole event system, similar to getListenerManager's 
lazy loading, in a way that other event systems can be used. The current event 
system would be the default using the lazy loading system mentioned above.

I realize this would be a large change to the base code, but it would also help 
to modularize the different systems used, which is always good.

Original issue reported on code.google.com by entityreborn on 2 Jan 2013 at 7:53

[GoogleCodeExporter]

Why couldn't you make your own listener manager? You could extend 
ThreadedListenerManager or just use the ListenerManager interface. This is 
somewhat similar to what quackbot does: Run verification that the bot isn't 
locked for the user, channel, or server; if everything passes run the command.

The only thing I haven't done is make an event for each line of output, which 
would enable you to "reject" certain output lines. I used to have this in the 
code base but removed it for being extremely complex

Original comment by Lord.Qua...@gmail.com on 2 Jan 2013 at 8:05

• Changed state: Accepted

[GoogleCodeExporter]

This might come from how my other (python) bot works.

As I mentioned, one of the issues with the current design is there is no 
priorities, so any filtering or cancelling might fire after other listeners 
already have received the input. Having said that, I guess a custom Manager 
could handle that.

One hangup I have is that the architecture is class based. Once again, a custom 
Manager could take care of that. 

My other bot uses decorators with arguments both for PRIVMSG triggers as well 
as raw IRC events, making the plugin much more flexible. (Plugins don't handle 
trigger characters or if the bot triggers via nick, but that's besides the 
point, this is a library, not a full bot implementation.)

Original comment by entityreborn on 2 Jan 2013 at 8:19

[GoogleCodeExporter]

Original comment by entityreborn on 5 Jan 2013 at 12:35

• Added labels: Component-Logic, Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Original comment by entityreborn on 7 Jan 2013 at 4:47

• Changed state: Invalid