I found the TODO list and am trying to implement modes for channels and users. I have come up with a design which depends on the following preconditions:

- user mode flags don't take arguments; - channel mode flags can have no argument, or - channel mode flags might have one argument, being one from the following types: * a single value (+/- l <max-users>) * a value to be added / removed from a list, which can either be + a nickname (+/- o <nick>) + some other value (+/- b <ban-mask>) - user modes which can be different per channel (chan-op for ex.) are channel characteristics

I intend adding a 'mode' slot in the 'user' class. This slot can hold a string with all characters for modes which have been set on the user. Implicitly this means that any character not present in the mode string has not been a user characteristic or has been 'MODE -<char>'-ed.

Further more do I intent do add a 'modes' slot to the 'channel' class. This slot will contain an assoc list of mode characters with their arguments. Each entry in the assoc list will be: - just the mode character itself if the mode does not take arguments; - a dotted list (#<char> . <value>) if the mode is a single value; - a list (#<char> &rest) if the mode maintains a list, where: * &rest are user objects if the mode takes a nickname for its argument; * &rest are strings otherwise.

In order to know which channel modes take arguments a list of channel modes is to be composed. I think this list should be stored in the variables.lisp file. I thought to name it *channel-modes*.

To be able to fill this list, there is the RFC which describes some modes, but to my understanding each network / ircd implements its own superset of what is in the RFC. To be able to process a MODE message, all these should be in the *channel-modes* list. Some questions remain:

* If that list is not complete: What to do with unknown MODEs in a MODE message? (My first intuition: don't take action on it; other handlers still can) * Should a new kind of event be introduced to signal the application the results of the parsed MODE message? (first intuition: no, let it reparse any MODE messages itself, if it wants to, as with all other messages now)

To be able to use mode names instead of mode identifiers (chars), I propose implementing two lists which map the identifiers to names like the *reply-names* list. (For channel modes this function can be integrated into the *channel-modes* list.)

Is this a sound design? What do you think? Expecting problems/bad match with the current implementation?

bye,

Erik.