Okay.
I devoted some more thinking time to this matter. Let me elaborate it a lil more.
In my friends RPG case, the IRC server is quite closed one. All players are expected to have their nicks registered, and when the bot connects to server/channel, it can perform whois query to everyone online. There will be a string telling if user is registered. Similarly, after a new person joins to a channel where bot is online, it can do a whois again (after a certain timeout so user has time to send the passwd to server). So basically user management and identification can be based on this information.
This however is not the usual case on regular servers. Besides I doubt any RFC specifies this nick registration, even less is it standardized. So in generic engine this is not suitable.
Other two methods I can think of are
1. password which is registered to bot. This is quite reliable (although creating a sniffer is not hard, and plain text passwords are thus quite unsafe). I doubt anyone would really want to obtain such a password. But sending passwords to bot is a pain. So this is somewhat uncomfortable.
2. Host mask / nick based identification is even less reliable, besides many people have dynamic IPs, meaning that many digits of the hostname/ip address should be masked off. This is not reliable at all, but it does not require user to do any password sendings etc.
More I ponder about this, more certain I am that all of these options should be supported, and user should have power to choose used option from configuration files.
Since my bot engine will be based on callbacks user can register to match some event on server/channel, I should also make it possible for user to disable user data handling from bot totally, and let user to create his/her own user management.
When I look these as requirements, I'll start seeing a total mess in implementation.
At the moment I have following idea/implementation.
There is config files which specify following things (amongst other)
Events triggering call of a callback function are in one text file as follows:
Code:
UniqueIdNumber callbackEventType Originator(chan/user) [triggerstring] [Chan/Privmsg/Dcc]
UniqueIdNumber is id which is used to bind an event and registered callback together.
callbackEventType is type of the triggering event, join/part/text string
Originator is channel or user(s). (Here is one problematic spot)
triggerstring is used with text events, If user who is in originator list sends text string matching to this, then event is triggered.
Chan/Privmsg/Dcc is location where text event can be detected.
Now. The originator.
I thought I'll use ; separated list of possible originators, and * as wildcard. So it could be something like #chan1;#chan2;nick1@hostmask1;nick2@hostmask2...
This approach would naturally work with nick@hostmask based identification. It would also work with registered nick based identification. But password based identification is somewhat harder to do in this manner... So I am a bit buzzled. Any ideas? (Well, solving a problem is half of the coding, right? Hence I feel this forum is appropriate place 
And when bugfixing and maintenance is 80% of the work, there's not much time left for implementation 
)
Okay. Let's assume I would postpone passwd based identification. Lets think of the implementation for a lil while.
If user of bot has not decided to build his own user management, then user identification should be done before callbacks are called. But since which user can trigger an action depends on the event in question, event should be evaluated before user management. So the place for this checking is quite clear.
So what information do we need about our precious user?
Nick and hostmask naturally. If user is registered or not. And from which channel/server did this command came from. Is there anything else? Somehow I do really have a code writer's block here.
Oh, I guess it might help you to answer, if I explained how this thing is aimed to work:
1. read events (and some other configs from config files).
2. register user callbacks (bind them with read events based on ID)
3. connect to server(s) and join channel(s)
4. listen incoming data, parse it into parts as IRC protocol specifies: <prefix><command><params>
5. Check if there's matching event
6. check if originating user has power to execute callback <this is my current problem>
7. execute callback.
I am also a bit uncertain how to handle connections to multible servers/channels. I am a bit tempted to end up multithreading here, but I hope I can survive without doing that. In my experience multithreading tends to cause more problems than it solves. (Ok, I have given up so much, that callbacks will be executed in own threads. I do not want to halt whole bot if user registers a slow callback ).
So here are my basic ideas. All suggestions are welcome!
Especially all tips on how to solve the user identification problem in not so messy way.
