
- IRCCS v2 -

 Bugs
 ----

	If you find any, you might be able to obtain some
	additional information about it by looking at the
	dumped hash files under ./database or ./dump . When
	submitting bug reports it would help to have the
	channel, nick or opers hash "section" where the bug
	occured.  Not the entire database, only the section
	for a particular nick or channel where the particular
	bug is effecting.  If you find that it is effecting
	all channels, nicks you should still only send a single
	section where you KNOW the bug exists.  An example:
	You register a channel but certain data is always corrupt.
	Don't send me a channel section that you didn't find this
	bug in, even though you assume it happens to all channels
	and, quite possibly, you may be correct, but the bug
	evidence may not be in the section you sent me unless
	you've actualy experienced it.  You can obtain a dump
	of any database hash using the operserv dump command
	/msg OperServ DUMP rchans  (or whatever database you want)
	will dump a file called rchans.dump into the ./dump
	directory.  This easy to read dump file can clue you in
	on many inconsistancies and/or bugs.  Make sure to watch
	the display or tail the log file (make sure it's enabled)
	'tail -f ./logs/service.log' before you check the dump
	file or you might only get a partial.  The log will let
	you know when the file has been completely dumped.

	- Database -

	The memo resequence routine in &writedatabase has a bug in it
	somewhere. It doesn't appear to effect anything except that
	there's a blank entry in the nicks.db. I'll find it eventualy.


Known limitations
-----------------

	- Messages -

	IRC servers have a limit to the amount of bytes
	you can send in one message.  If one of the routines
	exceed this limit it will go silently ignored.  I've
	added a check so it won't be ignored by the services.
	If one of your home made commands exceeds this limit
	you'll get a notice in display and/or log.  Even if
	you don't want logging I suggest you run logging and
	set it for priority messages only or you'll only catch
	the bug when you notice that you're missing some text
	or a user complains.  If you want to include a check
	that will chop up the pieces into biteable chunks then
	take a look at &send() and &sendtext() in the main
	module.  Installed there, it would be an easy fix.

	When I released this code there were no messages that
	exceeded the conservative amount of 400 bytes.  The
	problem is when a nickname of great length and or
	channel names combined with the existing text exceed
	the amount acceptable by the server.  This is why we
	need a check.  Certainly I'll install one later after
	I've had a chance to see how all my other programming
	has effected the speed of the engine.

	- Memory -

	IRCCS keeps a database of all users in memory.  It remembers
	who's on what channel, what modes they have and all the bans,
	channel modes and identified nicks a person had during their
	stay.  IRCCS probably records more information than the server
	it connects to.  In addition to this internal active database
	IRCCS must also remember registered nick and channel data.
	It keeps this in memory as well.  The implication is that you'll
	need at least the same amount of memory for IRCCS as you use for
	your irc server but most likely you'll need more.  If you don't
	like this idea, or you think that at least the registered nicks
	and chans data should be an active 'disk' database then converting
	it to such would be a trivial task.  I believe, however, that
	you'll need some version of DBM, which I expect most newer perl
	installations have, but quite possibly MLDBM, and is the reason
	why I've decided to use an 'in memory' base, which gets dumped at
	the interval you've specified in the config file and reloaded on
	startup.  I wanted to make this package as platform independant
	(portable) as possible.


Efficiency
----------

	- Dababase -

	I'm always learning new ways to do things.  More efficient
	ways usualy but sometimes I move backwards.  Saving/dumping
	the dabases is a very slow process, one that could be sped
	up using MLDBM, maybe, if you have all the prerequisits
	installed like Data::Dumper.  The main reason why my database
	write is slow, I think, is because of the eval() for each element.
	I could be missing something entirely but I spent 5 or 6 days
	trying to come up with a solution for this particular routine,
	other than using eval.  I wanted to be able to pass a single
	reference or hash name to a routine and make it dump it's
	data to a file for later examination and/or reconstruction.
	The solution I came up with, which is my original test, is
	contained in the main sub save() and consists of calling
	walk().  It can take several seconds for your databases to
	write and you may notice this lag if your system doesn't
	support fork, or perls ability to mimic it on those platforms
	where fork() isn't available.  If anyone discovers a better,
	quicker, solution that's just as portable I would appreciate
	the information.  If it's not already obviouse MLDBM is not
	immediately portable.  My idea is to allow people to be able
	to run this application from dos/win, or whatever platform
	has a relatively new perl version for it, and linux with just a
	base installation of perl.  Certainly I could have printed
	each element to the database seperately.  If you want to do
	this then the easyest way to determin what needs saving is
	to check the dumped hashes in the dabase directory.  %chans
	and %nicks do not need saving, these are transient bases
	used to keep track of channels and nicknames.  Registered
	channels, nicks along with the operserv hash, are saved for
	later retrieval in %rchans, %rnicks and %opcoms respectively
	which dumps to rchans.db, rnicks.db and opcoms.db.  Oh, don't
	forget %games (games.db).





