irc-go icon indicating copy to clipboard operation
irc-go copied to clipboard

restore some kind of global callback functionality

Open slingamn opened this issue 3 years ago • 4 comments

thoj/ircevent (which we forked from) allowed passing * as the command name to AddCallback, in which case the callback would apply to all events. I removed this when I forked because I didn't see a clear use case at the time.

Possibilities:

  1. Restore some version of star callbacks. (In the case where a common handler is used for all commands, with internal logic for reading (*ircmsg.Message).Command, this DRY's the enumeration of the possible commands between AddHandler and the handler itself.)
  2. Add a separate callback handler that takes the raw IRC bytes from the wire, rather than a parsed message (e.g. for implementing a raw traffic log)

slingamn avatar May 24 '22 13:05 slingamn

I've just migrated to this module for the improvements over the original, just realised I am actually missing this feature and have some broken functionality.

I'm going to specifically add callbacks for the commands I'm handling but would be good to reintroduce this once I can.

surskitt avatar Jul 21 '22 21:07 surskitt

Thanks for the report, it's great to have feedback from real-world projects using the library :-)

I was leaning towards option (2) which wouldn't have directly addressed your use case. It sounds like you were able to fix the issue by enumerating the relevant commands and manually calling AddCallback for each one?

slingamn avatar Jul 22 '22 04:07 slingamn

I'd like to have a callback for unhandled commands/replies that don't have a callback set. This makes it possible to display all IRC commands coming in for a client even if it doesn't necessarily understand them but avoids them being lost in the void.

So something like SetDefaultCallback(func(ircmsg.Message)) would be nifty and would only be called for real IRC events, not the convenience ones like connect and disconnect callbacks and only if there are no callbacks registered for the event.

Additionally having a catch-all for all events would help with custom loggers where the downstream developer would want to log all incoming IRC events in a structured manner. I would like to use such as well but it's not a strict requirement because I can set a logger for the connection that will already get the raw lines logged. Having it separately as a SetGlobalCallback(func(ircmsg.Message)) would be more idiomatic than using * I think.

hifi avatar Jul 16 '23 10:07 hifi

I started work on this. I'm currently planning to add two new APIs:

  1. AddDefaultCallback, which will apply to any lines that are not handled by any other callbacks (but note that the library adds some callbacks of its own, e.g. for 001 RPL_WELCOME and NICK, so it may not be obvious which commands are completely unhandled)
  2. AddRawCallback, which will receive the raw IRC line (probably the parsed line in addition) unconditionally

slingamn avatar Jul 17 '23 15:07 slingamn