I agree, but as explained earlier plugins need to be able to affect what happens after plugin has processed an event... which is why using the existing listeners is not the ideal solution in 9 cases out of 10... to be completely honest I even considered not using any listeners, except timermanager and settings, for plugin hooks at one point.
Currently it uses the following listeners (in addition to aforementioned): ClientManagerListener::ClientConnected ClientManagerListener::ClientDisconnected QueueManagerListener::Added QueueManagerListener::Moved QueueManagerListener::Removed QueueManagerListener::Finished And in doing so it already creates the following limitations, - Plugin can't stop certain hub from being connected to. - Same about being unable to prevent certain file from being added to Queue. So to put it in other words, for events that can be seen as purely informal like removal of hub or queue item, or the download destination for queue item being changed etc. the listeners are fine. To use listeners (as they are now) for everything, however, would mean to limit plugin to being little more than an observer. This is fine I guess for plugins that will do things like: SFV/Antivirus checking or Report/Log generation, but for anything else it is too restrictive kind of defeating the purpose of plugins. While it can be argued that overriding user action such as adding download or connecting to a hub is not desirable action by a plugin, the valid counter argument for that would be that since every plugin is user installed user would not install a plugin that does this without some logic behind it (unless they want to make their own life hard, the point being there is consent from user to this to an extent). Regarding desirable and undesirable behavior from plugins, there are two options to address this, one (the easy) is to implement guid based blacklisting of some sort for rogue plugins and the other would be to generate a "permissions" request, on install, based on what hooks the plugin subscribes to. The former approach has no impact on the API while the later might need subtle modification to it (I haven't brought this up since it is only very externally part of the API). -- Plugins support https://bugs.launchpad.net/bugs/587597 You received this bug notification because you are a member of Dcplusplus-team, which is subscribed to DC++. Status in DC++: New Bug description: Ok, I'll leave out the sales pitch... here is a potential patch for adding support for plugins to DC++, compiles cleanly (ie. shouldn't generate any warnings) under mingw and visual studio of course and has been tested and working. The code itself has been in ApexDC++ for a while so it has gotten real life use as well, of course migrating it to clean DC++ needed a few changes here and there but nothing major. Should also compile and work on linux as it is... but this I have not had chance to test at all so that is just on paper for now. The major difference between this patch and what's in ApexDC++ is that it does not include a full settings page for plugins which ApexDC++ has. This is simply because I don't know a squat about DWT. Instead this patch has set of chat commands added, so you can play around with the plugins, but if this gets accepted then I certainly hope someone is willing to invest into a settings page for usability sake. Oh and few changes to the code come directly from bcdcpp, you'll spot them I am sure :). As for the plugins currently three exists.. a pure C sample that (you guessed it) really doesn't do anything productive and then a plugin version of bcdcpp's lua (this one is pretty direct port, so it is C++). The third one is not so impressive... it adds support for various media player chat announces (spam is too negative of a word), although primarily I created it to proof that it is possible to make a plugin that modifies the GUI, even though the API itself has little to no support for such plugin (on windows anyways), The first two plugins can be compiled with both mingw and visual studio and are also hopefully linux friendly, the third not so much. Oh and you can mix plugins... so mingw compiled dcpp will cope just fine with visual studio compiled plugins or vice versa (obviously this also means that the stl's used can be different). In theory you should also be able to create plugins with languages such as VB and Delphi but this very much theoretical. Well do what you want with it... it's posted now. _______________________________________________ Mailing list: https://launchpad.net/~linuxdcpp-team Post to : [email protected] Unsubscribe : https://launchpad.net/~linuxdcpp-team More help : https://help.launchpad.net/ListHelp
