search

bitwalker / exirc

IRC client adapter for Elixir projects
http://bitwalker.github.io/exirc/
MIT License
152 stars 37 forks source link

IRCv3 Extensions Handling #29

Open rockerBOO opened 9 years ago

rockerBOO commented 9 years ago

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

Happy little accidents

bitwalker commented 9 years ago

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?

rockerBOO commented 9 years ago

I think that sounds great. How would this be done? I would be glad to start adding the CAP (capability) support.

bitwalker commented 9 years ago

@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?

rockerBOO commented 9 years ago

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 =).

bitwalker commented 9 years ago

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.

rockerBOO commented 9 years ago

Just had some time to look this over. Looks great to me.

:+1:

OvermindDL1 commented 5 years ago

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?

OvermindDL1 commented 5 years ago

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