[cl-irc-devel] RFC: Add modes to users and channels

[Erik Huelsmann]

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.

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz