Just a simple unit test for CModules that checks that the legacy hooks
get called and any modifications flow back to the original CMessage
object as appropriate.
This naming is a bit hairy. I chose CTextMessage because this type of
message carries a text argument. Alternatively, it could be also called
CPrivateMessage, because the IRC protocol calls it PRIVMSG. On the other
hand, ZNC module hooks use the "Priv" naming convention for private
messages. It would look a bit weird to have OnChanMsg(CPrivMessage)...
More details and reasoning of the merge in the previous commit message.
OnUserAction(), OnUserCTCP(), and OnUserNotice() don't separate private
private and channel messages. A module could even redirect a message by
modifying its target, so technically, if they were two distinct types,
the type of a message could change on the way.
The original reason for the separation was that at some point during
CMessage development, GetChan() didn't exist in CPrivXxx, but only in
CChanXxx message types. To achieve cleaner implementation, the getter
was later promoted to CMessage and made return nullptr for non-channel
specific messages. From this point of view, the separation is also no
longer necessary since the CPrivXxx and CChanXxx types are API-wise
identical with each other.
It's getting a common pattern to call AsLower() or MakeLower() on
the arguments passed to WildCmp(), we might as well add this for
convenience. It's tempting to make it case-insensitive by default,
since pretty much any IRC related comparison should be, but that
could potentially break some existing code.
- PASS [user[@identifier][/network]:]password
- USER user[@identifier][/network] ...
NOTE: There's a slight ambiguosity with the '@' character, which happens
to be a valid character in usernames, but also acts as a marker for the
identifier. Therefore, '@' is considered as part of the username if it's
followed by non-word characters (as in an email address), otherwise as
a marker for an identifier.
This is only an enabler for #343. The rest can be done with modules:
- managing client ID specific playback buffers
- filtering channels based on the client ID
The reason this should be part of ZNC core is that only global modules
have access to OnUnknownUserRaw(), which is needed to capture USER/PASS.
First of all, the aforementioned modules shouldn't be global. Furthermore,
it would be possible to have only one module that parsed and removed the
client ID so that ZNC core woulnd't choke.
J-P Nurmi