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 -->
#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 -->
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 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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:
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:
How #501 is parsing things twice?
What do you mean by "type" and "command"? Any example?
#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.
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...
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
#1000