Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IRCv3 Extensions Handling #29

Open
rockerBOO opened this issue Jun 20, 2015 · 8 comments
Open

IRCv3 Extensions Handling #29

rockerBOO opened this issue Jun 20, 2015 · 8 comments

Comments

@rockerBOO
Copy link
Contributor

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
Copy link
Owner

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
Copy link
Contributor Author

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

@bitwalker
Copy link
Owner

@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
Copy link
Contributor Author

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
Copy link
Owner

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
Copy link
Contributor Author

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

👍

@OvermindDL1
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants