Log Named Messages
Logging has two states: per-channel or global. Global logging is useful for, e.g. the SLIME REPL. When global instead of per-channel, the destination is always included, e.g. <user:#channel>
instead of <user>
. Per-channel logging is useful for creating log files for each channel that the IRC client is connected to, but cannot be done without keeping some state. Actually maintaining the log files themselves belongs in a separate issue.
Logging is closely tied to parsing, since it is the most basic thing that can be done to a parsed incoming IRC message. That is, the most basic action is displaying it properly to show that it was parsed properly. However, some IRC commands (i.e. outgoing messages) need to be logged because the server sends nothing back in response. Most commonly, this includes PRIVMSG and NOTICE.
In general, this library distinguishes between commands (sent by the IRC client to the server without a source prefix) and messages (normally received by the IRC client from the server), but commands are messages and some outgoing commands (such as PRIVMSG) need to be logged while sent. However, in most cases, the commands that the IRC client sends do not need to be logged because the server will respond with something that should be logged instead. These responses can include errors if the command is not accepted, making the incoming response message more useful than the outgoing command.
Most, but not all, of the IRC messages are documented here.
This issue only covers named messages. Numeric messages (that have an integer code instead of an upper case name) are sent by the server automatically, usually in response to certain messages. These are often specific to a certain IRC daemon and will go into their own issue.
Correctly parse and log:
- PRIVMSG
- NOTICE
- PRIVMSG CTCP ACTION
- PRIVMSG CTCP
- NOTICE CTCP (NCTCP; CTCP response)
- PING
- PONG
- JOIN
- PART
- KICK
- QUIT
- NICK
- MODE (channel)
- MODE (user)
- TOPIC
- INVITE
- WALLOPS?
- KNOCK?
Notes:
- PONG is only sent. All of the rest are only logged when received except for PRIVMSG and NOTICE, which are both sent and received.
- When logging per channel, both QUIT and NICK require state-tracking to determine if the user is present in that channel because they are only sent once, globally, rather than per-channel. This in turn requires parsing RPL_NAMREPLY (and RPL_ENDOFNAMES), which in turn requires parsing RPL_ISUPPORT for PREFIX, which is removed if present when building the user list from the name list. The stored present names need to update on JOIN/PART/KICK/NICK/QUIT.