Add user query extension
cc @slingamn
How about one QUERYUSER command with subcommands + (add), - (remove), and L (list), similar to MONITOR?
I'm not in love with the single-character subcommands, I would prefer explicit words as done in e.g. metadata-2, but that's purely cosmetic.
I think the list subcommand could be a better idea instead of implicitly sending a (potentially) big list upon conn registration: the list can be quite large and implicitly sending replies has been problematic in the past (e.g. no-implicit-names, or the messy JOIN burst management).
I wonder if we need to introduce some kind of paging…? I would like the spec to stay as simple as possible, and in practice the list should be limited in size or else it would be annoying to display in a sidebar UI.
Any thoughts on batching QUERYUSER from the server (particularly if there were an L command for listing?)
Sounds like a good idea either way!
I still think this needs an implementation considerations section on limiting data growth.
Yup, was definitely something I wanted to add. Done!
For classic IRC client UIs like gamja, the list is displayed in the sidebar alongside channels, so the user is likely to clean up old and unused user queries to avoid cluttering the screen too much. For clients like Goguma, the user typically never closes older user queries, since these get naturally pushed back to the back of the list. I've wondered whether we needed to accommodate for this in the spec, but I haven't found anything we could do differently.
I'm not in love with the single-character subcommands, I would prefer explicit words as done in e.g. metadata-2, but that's purely cosmetic.
Fine by me :-) I just prefer subcommands over multiple commands, for cleanliness / extensibility.
I think under a normal workload, data size shouldn't really be a concern and it should be fine to send all open queries as part of (technically after) the registration burst, without pagination.