Re: [NeoStats-Devel] SeenServ

Justin Wrote:

> Without seeing the code, its hard to suggest a option. Anyway, you can
check
> it in now at http://svn.neostats.net/svn/SeenServ/trunk :)

it's on it's way up now.


> Right now, are you using a list or a hash? Using a list means that you
have
> to search through all the records one by one till you get a match. As the
> records get large, this could cause performance problems. If you use a
hash,
> and use the nick as the key, you can pretty much directly retrive the
record
> without having to write compare functions etc.

using a hash tends to restrict it to doing lookups on nicks only, and
/whowas is a better way to doing a lookup of a particular nick (excepting
nick changes).

if using SEENNICK in SeenServ it looks for a exact match of the nick, but if
using SEEN it looks for a wildcard match of the entire
nick!user@<host|vhost> which is why i went for the list. appending the
records keeps them all in time order, and when searching it checks from the
end to the begining untill it finds a match. i figured that having to search
the entire file would be more of a performance hit than the memory saving
would warrant.

although on specific nick lookups it would be better just reading from the
database directly instead of the list. i still have to add checks to see if
nicks are currently online before checking the list to try to save
resources/time.

> The database is just as simple (I think, without seeing the code again,
I'm
> just guessing...) but if your storing using the nickname as the database
key
> when you save, you could just to a DBGET command to retrive the seen info
> for that nick. If it return NULL, then it doesn't exist and you tell the
> user so, if it does exist, well, you only need to keep it around in memory
> for the request, and then can drop it later... (but, for performance
> reasons, you might want to have all *online* users loaded in memory, and
use
> your incremental saves to update the DB with changes... This avoids having
> to do DB calls on all entries... Then when a user issues a !seen command,
> you first check the "online" hash, and if its not there, issue a DB call,
> and if you don't get anything tell something witty to the user. :)

I was going to get the functions right then start adding the witty responses
:)

the above was my thoughts on it, but I've never thought I am right all the
time (just most of it:)) and am quite willing to listen to other ideas/ways
of doing things, and accepting help where needed.

DNB