No Subject

[Jeremie Miller <jeremie@netins.net>]

I've been thinking about the way "modules" work on the server side, or,
more correctly, within the Jabber transport.  For those that haven't
looked at it yet, it currently works like this:

 - Each module exposes a set of functions to be called by the server
 - When a user connects each module is asked to authenticate it
 - The module that authenticates that user then "owns" that user
 - Most events that happen for that user(ex: adding user to roster) are
   passed to that module's exposed function for it

The problem with this setup is that each module cannot leverage
functionality in another module.  Say you had an easy way to authenticate
users via Radius and wanted to store their offline messages in a MySQL
database, you'd have to write your own module from scratch when other
modules might already contain all of the needed functionality.

My proposal to correct this limitation would be to add a "group" idea to
the server, so that each user belonged in a group.  Then each group could
be configured to just use bits and pieces of certian modules, or all of
one module like it currently is, much more configurable.  All of the auth
handlers would return a group ID when they autorize a user.

Example, start with the foloowing modules:
mod_mysql: provides all handlers based on DB tables
mod_unix: provides auth and info/search only via /etc/passwd
mod_roster: file based fast hashed roster management
mod_archive: stores all messages for web based searchable archive

And have the main config file like:
<users>
	<locals> #mod_unix returns this group
		<offline>archive</offline>
		<roster>roster</roster>
		<message>archive</message>
	</locals>

	#mod_mysql returns this group, default all of it's users to itself
	<general default='mysql'/> 

	<special>
		<offline>mysql</offline>
		<roster>roster</roster>
		<message>archive</message>
		<status>mysql</status>
	</special>
</users>

Obviously, this is a really simplified example, but hopefully enough to
convey the idea.  All the modules are asked to authenticate a user, and
when they do they return one of the group names from above(locals,
general, special) which the server uses to figure out what module's
handlers to call for that user.

If there's no problem with this I'm going to go ahead and try this out as
soon as I get a chance... it's obviously an improvement from what's there
already :)  Besides, there are lots of handy little modules I'd love to
write.

oAo,

Jer