[Exb-devel] Exb3 Feature Ideas

[alex r. <bs...@ba...>]

As I promised, here are the features and ideas I pondered.. Including
some from wataru's list that are still applicable.

Further discussion over at
https://sourceforge.net/forum/forum.php?thread_id=647230&forum_id=128807

And you've all be whining at me to contribute more on this version.. So
contribute, damnit! 

exb3 - "Cheshire" (and quite possibly the future, but perhaps not ;)
[11:35 PM 2/19/2002]
Draft 1.1 - bse

	* "internal" plugins 
 		- to add internal features to export to modules, or
provide functionality
 		  (such as a server to provide an interface to conenct
remotely to the bot)
 	* "external" modules - mods, as per 0.2

 	* module prioritising and scheduling
 	
 	* threading - to allow modules to run without being dependant on
network reads

	* using non-blocking IO for network reads - similar to how you
use select's in C/C++
	
	* JavaDoc throughout

	* xml configuration!

	* packaging!
		exb.core
		exb.core.net
		exb.log
		exb.config
		exb.irc
		exb.modules
		etc...

	* levels of logging
		(wataru contributed these.. ta)
 		- fatal() info() warn() debug()
 		  the config file could then have a LOGGING option,
integer value:
 			* 1 - fatal
 			* 2 - fatal, info
 			* 3 - fatal, info, warn
 			* 4 - fatal, info, warn, debug
 		  Or a comma separated list so you can pick and choose
which logging 
		  option to use, whichever way is better.

 		  - Fatal being anything that causes the bot to die;

		  - Info is anything useful for the user, but not
necessarily wrong, nor
		    debugging (nick/mode changes, people joining etc)
this could be what chat.log 
 		    keeps a record. (but it should keep chat.log up to
date so that 
		    modules can use it, so even if they don't specify
logging=info it wont
		    debug.log and stout it, but it will chat.log it) 

		  - Warn being anything that's not fatal but is wrong;

		  - Debug being our crap but users don't need to see by
default.

		  This overall should reduce *some* overhead so that it
doesn't debug when
		  it doesn't need to. plus is a nice little feature :)

		  Fatal should always be logged to debug.log at least,
even though they
		  don't specify it in LOGGING. this way although it may
not put it  to
		  stout, they can peak in the log file and find out why
the bot  doesn't 
		  load/connect and upset them.



	* better auths features

	* better method help
		(thanks again, wataru)	
 		* helpTitle()
 			- could insert ident, author and version
		* helpDescription()
			- what the modules purpose in life is generally
		* helpCommand(command, description, required_auth)
 			- e.g.: helpCommand("wtf <term>", "display the
meaning of <term>", 0) 
			  required_auth then will allow helpCommand() to
not show 
			  help for users without said auth level.
	
	
	*** crap that isn't really "features", more programming ideas
i've pondered for a while
	* keeping the core small and tight, with almost *everything*
running via internal plugins,
	  this way if we add another irc command the IRC.plug just has
to be reset instead of the 
	  whole bot. As i see it, the core should contain basic
networking code, and the threading
	  scheduling stuff, so we can load/unload features as
requirement says.
	  
	* some plugins will need to be loaded by deafult, out of user
control.. we can discuss these
	
	* we can also discuss the types of "plugin" the bot needs - IRC
commands, channel handling, etc.
	

	I think that's about it.. we can add/remove/pontificate ideas as
the mood takes us.
	


-alEx 
-www.bakterium.com