Several weeks ago I saw a commit mail comming through the cl-irc-cvs mailing
list. Whenever I commit (yesterday and before the debian commit) I don't see
a mail comming through the list. Is the repository configured in such a way
that it does not always generate a commit mail?
bye,
Erik.
--
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info
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
