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.
The enum is a bit more verbose, but leads to more readable code:
str.Equals("foo", true)
// vs.
str.Equals("foo", CString::CaseSensitive)
Deprecate the old Equals() and leave out the length parameter
from the new version => use StartsWith() or StrCmp() instead.
When a job was cancelled after its runThread() method finished, but before the
main thread noticed this and reacted, we would just run runMain() before and
pretend the job finished normally.
However, with CModuleJob this means that runMain() might get called for a module
which is currently being destructed. This has bad effects with virtual functions
and thus causes problems. It's better to just really cancel the job instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds CThreadPool::cancelJob() and cancelJobs() which can cancel a set of
jobs synchronously. These functions only return when the job was successfully
cancelled.
It tries to cancel the jobs as quickly as possible, skipping any callbacks on
CJob that were not yet called. A job that is already running can use
CJob::wasCancelled() to check if it should quit.
Signed-off-by: Uli Schlachter <psychon@znc.in>
