Implement full CTCP spec

[SoniEx2]

You should implement the full CTCP spec, available here: http://www.irchelp.org/irchelp/rfc/ctcpspec.html

[aatxe]

I believe all of this except for DCC and ERRMSG are implemented. I suppose it's worth adding ERRMSG, but I don't see any reason to support DCC.

[SoniEx2]

What about inline CTCP and escape codes? Also I don't think anyone implements ERRMSG, so you shouldn't. Also any way to expose CTCPs to the user? (e.g. for this)

[freddyb]

I'm interested in implementing DCC in the future (probably in the fall). I'll do some experiments, starting with some minor plumbing to support parsing DCC sends to the IRC client, so users of this care can write their own code to handle a download. As a next step, one could write something that allows downloading into a buffered slice or a file.

I'm quite interested in this feature, but if there are strong feelings against this, I'm happy to do this someplace else. Either way, I'd be thrilled to find some guidance to make it play nice in combination with this crate and be reusable for others.

Any thoughts?

[aatxe]

Hi @freddyb,

Sorry for not replying sooner! I think the most sensible way to implement DCC (and for that matter, also to implement the full CTCP spec as this issue is suggesting) is to provide an additional crate that you could hook into within message handling code. The reason for this is that the full CTCP spec requires you to be able to have multiple CTCP messages within ordinary IRC PRIVMSGs, and I don't want to make the typical use case of dealing with non-CTCP messages (i.e. the vast majority of them) ergonomically worse. For DCC, it especially makes sense because after a bit of IRC exchange, you move to a different protocol with a direct connection to the other partner.

I'm happy to offer advice and assistance when you attempt this though, even if it is as a separate crate! Please let me know when you're working on it! 😄

[freddyb]

Thanks for the encouraging response! I've been thinking about doing this in its own crate for a bit and will take a closer look later. (I'm on vacation and won't access a computer before August.) Am June 20, 2018 10:36:14 PM UTC schrieb Aaron Weiss <[email protected]>:

…

Hi @freddyb, Sorry for not replying sooner! I think the most sensible way to implement DCC (and for that matter, also to implement the full CTCP spec as this issue is suggesting) is to provide an additional crate that you could hook into within message handling code. The reason for this is that the full CTCP spec requires you to be able to have multiple CTCP messages within ordinary IRC PRIVMSGs, and I don't want to make the typical use case of dealing with non-CTCP messages (i.e. the vast majority of them) ergonomically worse. For DCC, it especially makes sense because after a bit of IRC exchange, you move to a different protocol with a direct connection to the other partner. I'm happy to offer advice and assistance when you attempt this though, even if it is as a separate crate! Please let me know when you're working on it! 😄 -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #49 (comment)

-- Sent from my tiny mobile computer.