bitwalker
IRCv3 Extensions Handling
As a general question, does this library wish to handle these specifically?
A lot of the extensions are sort of odd cases, but if servers are implementing a ircv3 spec, it might be worth it to support it. Or maybe a exirc-extensions library with the extra extensions?
https://github.com/ircv3/ircv3-specifications/tree/master/extensions
I think it would be great to add support for it! I'm thinking I'd like to approach adding the ability to plug in these kinds of extensions, and implement the v3 extensions within exirc using that functionality. This way people can handle adding custom extensions as well, but we don't have to maintain a separate lib for the v3 stuff. Thoughts?
I think that sounds great. How would this be done? I would be glad to start adding the CAP (capability) support.
@rockerBOO I've pushed a branch feature/extensions. Take a look at lib/extensions/* where I've defined a behaviour for extensions, with an example extension for handling CAP LS responses. In client.ex you'll see in the diff where I plugged this in. Right now it's pretty much read only (though I added support to ClientState to store capabilities returned in the CAP LS response).
Could you take a look and let me know how we can improve this so that the support is flexible enough to support implementing IRCv3 extensions?
I am honestly not familiar enough with the extensions to know what would be flexible. Might be good to make the extension names match the name in the specification "cap-notify" CapNotifyExtension.
Might be good to think about a adding in a custom command handler too. Some servers I am interacting with, adding capabilities sometimes adds new commands. They won't be specifically in an extension, so some custom way of handling them might be good.
Thanks bitwalker! Been helping me out a lot =).
Good point on the extension naming!
I'm pretty unfamiliar with the IRCv3 stuff as well at the moment, but that link you provided has some decent documentation, it'll just take a bit of time to wrap my head around what all the implications are.
The extensions infrastructure I've added should allow you to write "unofficial" extensions (such as a capability not defined in a spec, but added to a server anyway), but if there are awkward bits, let me know and I can tweak how it works.
Could definitely use the away-notify V3 capability so I could get NOTIFY messages, has this gone anywhere or should I look into other methods?
It ended up being really easy to implement it in your own handler, the direct spec page if anyone wants to do so themselves is at: https://ircv3.github.io/specs/core/capability-negotiation-3.1.html