It's been a while since this has been discussed I think, but the lack of DCC support is really starting to bother me at this point. I'm willing to implement this myself, but I'm not sure how. Now, I'm not talking about support the way the old DCC plugin provided it, but something more flexible. Keeping connections alive, allowing users to execute commands (eliminating the need for .more in the process), but allowing other plugins to open a custom connection aswell with their own interface, or just a simple open-spam-close like thing, like the old DCC plugin. And don't forget file transfers.

This is going to be my personal view on this, which is known not to be on the same wavelength as other developers', so feel free to critic ofcourse.

If I were to implement it, I'd probably do it in a way that benefits other plugins aswell, it wouldn't just be a plugin itself like the old DCC plugin. It just seems like core functionality to me, it's 'part' of IRC, atleast that's probably what a user or plugin author would think of it. And it shouldn't be all that hard to just open and use a DCC connection the way you want.

The thing I'm kinda stuck with though, and that I've encountered before, is how to efficiently listen to these DCC sessions while they're running. Seeing as, to me, this is basic IRC functionality, it's only logical that this simply works along with the rest of the bot. But the bot itself has drivers that are specific to just the IRC connection itself.

Jeremy told me, the previous time I bumped into this, that I should be writing a separate driver for it. But how will that leave people any choice whether to use twisted for it (or not)? Wouldn't that mean polling the IRC and then the DCC connections after eachother, instead of all in one go? It just seems kind of odd to me. (but I've never really been fond of supybot's driver thing anyways :p)

I also took a look at Ali's gateway thingy, and that just forces you to install twisted.

Maybe twisted is the best way to go, but again, I see this as basic functionality, and you either offer your users the choice of which driver to use, or you don't.

So uhm... discuss!

Twisted is the best way to go, and you should definitely talk to ali about this -- he's written plugins which provide services to other plugins, and has the most experience with it.

Anyone who could reasonably run an IRC bot that does DCC should be able to handle installing Twisted. You could also (because of the new plugin format) include a "fat" plugin which included Twisted, but that seems somewhat wasteful.

Anyway, this is a feature which would *gladly* be accepted into the core, as long as it's done well.

Jeremy

supybot-sumo

But seriously, it should be relatively uncomplicated to implement this using Twisted (certainly easier than Sshd). If you want a suggestion, the current Sshd (0.2) would be the best example (of mine) to go from, and I am happy to answer any specific questions.

It is worth noting that the use of Twisted is just something that will save you hours in the long run. The essential way that Sshd communicates with Supybot is independent of Twisted and would be identical regardless of network backend. You could easily write your own asynchronous networking backend, but it would not be mature, tested, and regularly fixed and updated. One option is to use Twisted now, and replace it with something home-spun later.

Good luck, and make sure to let me know if you need anything. I could probably whip up a basic plugin for DCC in a couple of hours, but don't have time, unfortunately, at the moment to polish it into something core-worthy.

Ali

I have put a simple DCC plugin in supybot-plugins. All it does is respond to DCC requests by opening a DCC connection to the user, and responding to standard commands over that DCC connection.

Par example:

    * Offering DCC CHAT to testbot
    * DCC CHAT connection established to testbot[127.0.0.1:58148]
    testbot: Connected to Supybot Dcc interface.
    ali: whoami
    testbot: (whoami) ali
    ali: list
    testbot: (list) Admin, Channel, Config, Dcc, Misc, Owner, and User
    ali: exit
    * DCC CHAT to testbot lost (Remote host closed socket).

Now please tell me what features you want added, if any, or add them yourselves.

Ali

Okay, I'm looking into this. There's a couple of issues I've encountered so far though:


First of all, messages sent through the DCC connection are queued like any other IRC message, meaning they will get throttled. That sortof defeats the purpose of a DCC connection, especially in my case.

My initial guess was to solve this with a proxy, but that doesn't seem to be possible either. The DCC plugin ali put up on darcs uses feedMsg to actually execute commands. feedMsg only takes the message though, and not an irc object or proxy object. feedMsg is a method of the actual IRC object and just passes 'self' to the callback.

It doesn't look like there's a way around feedMsg either, it contains quite a bit of logic. If I could just stick a proxy in there, I'm guessing it'd be as easy as having queueMsg be an alias for sendMsg. But that seems to impossible. Any suggestions?


Now second, all this Irc object trouble made me think of another thing: what if the Irc object is destroyed? Won't that invalidate the Irc object, and possibly even the Dcc plugin object? What if a session is in progress then? I'm guessing it'd raise a couple of problems atleast.


Third, how would I make Dcc functionality available to other plugins? The cleanest way to do this would be exposing a couple of classes a plugin could inherit from. But how to do that? Ali is using a bit of a hack right now in the Pastebin plugin (IMO):

try:
PageModule = world.ircs[0].getCallback('Webserver').classModule
PageClass = PageModule.plugin.PluginPage
except Exception, e:
log.error('Webserver plugin must be loaded')

But I can't think of any other way either.