Suggestion: introduce dedicated message/command types #305

Closed
opened 2026-10-05 04:11:56 +02:00 by adam · 4 comments
Owner

Instead of passing around raw string lines or a variable amount of tokens, dedicated message and command types could offer a convenient API to access & modify the relevant attributes of "lines" transferred between IRC servers, ZNC, and the clients. This could potentially help making the module hook API simpler and to avoid the need of ever parsing "things" twice (see for instance https://github.com/znc/znc/pull/501).

Message (received from an IRC server) attributes:

  • sender/prefix/nick/ident/host
  • type
  • command/number
  • parameters
  • timestamp
  • tags
  • raw data (?)
  • ...

The buffer storage could store these message types so the same attributes could be accessed later eg. during the buffer playback or whatever modules might want to do.

Command (sent to an IRC server) attributes:

  • type
  • parameters
  • raw data (?)
  • ...
Instead of passing around raw string lines or a variable amount of tokens, dedicated message and command types could offer a convenient API to access & modify the relevant attributes of "lines" transferred between IRC servers, ZNC, and the clients. This could potentially help making the module hook API simpler and to avoid the need of ever parsing "things" twice (see for instance https://github.com/znc/znc/pull/501). Message (received from an IRC server) attributes: - sender/prefix/nick/ident/host - type - command/number - parameters - timestamp - tags - raw data (?) - ... The buffer storage could store these message types so the same attributes could be accessed later eg. during the buffer playback or whatever modules might want to do. Command (sent to an IRC server) attributes: - type - parameters - raw data (?) - ... <!-- github-sync-id:28986307 -->
adam closed this issue 2026-10-05 04:11:56 +02:00
Author
Owner

How #501 is parsing things twice?
What do you mean by "type" and "command"? Any example?

How #501 is parsing things twice? What do you mean by "type" and "command"? Any example? <!-- github-comment-id:37061944 -->
Author
Owner

How #501 is parsing things twice?

#501 itself is not parsing things twice, but that will happen if two modules use it on raw lines. of course, the earlier proposed solution of passing tags as an additional argument to hooks would work as well, but i think a dedicated type would nicely encapsulate all these attributes and make it possible to access any attribute you want in any relevant hook you implement.

What do you mean by "type" and "command"? Any example?

Message "types" could be fast to compare enumeration-like (privmsg, notice, join, part, quit, kick, mode, nick, numeric etc.) whereas message "command" could expose the actual IRC protocol command as in "PRIVMSG", "NOTICE", "301" and so on. Not sure if you want both, but usually one would check the "type" if necessary (for example, in a targeted hook you would already know the type), and the raw "command" could be useful for more extreme use cases (like altering messages on the fly).

Command types would be probably pretty much the same basic set + perhaps things like away, list, motd, names, stats, time, who(is/was) or so...

> How #501 is parsing things twice? #501 itself is not parsing things twice, but that will happen if two modules use it on raw lines. of course, the earlier proposed solution of passing tags as an additional argument to hooks would work as well, but i think a dedicated type would nicely encapsulate all these attributes and make it possible to access any attribute you want in any relevant hook you implement. > What do you mean by "type" and "command"? Any example? Message "types" could be fast to compare enumeration-like (privmsg, notice, join, part, quit, kick, mode, nick, numeric etc.) whereas message "command" could expose the actual IRC protocol command as in "PRIVMSG", "NOTICE", "301" and so on. Not sure if you want both, but usually one would check the "type" if necessary (for example, in a targeted hook you would already know the type), and the raw "command" could be useful for more extreme use cases (like altering messages on the fly). Command types would be probably pretty much the same basic set + perhaps things like away, list, motd, names, stats, time, who(is/was) or so... <!-- github-comment-id:37065741 -->
Author
Owner

Some ancient thing that I once wrote and which is remotely related (and in a way also not related at all): https://github.com/psychon/znc/commit/aa3295260239930d248181f9304f7cbe6b05c431

Some ancient thing that I once wrote and which is remotely related (and in a way also not related at all): https://github.com/psychon/znc/commit/aa3295260239930d248181f9304f7cbe6b05c431 <!-- github-comment-id:37075226 -->
Author
Owner
#1000 <!-- github-comment-id:131983259 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#305