linuxdcpp-team team mailing list archive

[Steven Sheehy <587597@xxxxxxxxxxxxxxxxxx>]

Personally, I would prefer a less powerful but cleaner and safer plugin
system that could not affect what happens after the plugin processes the
event. Cleaner because it could use the listener system for all
communication. Safer because it would be read only data passed and could
be processed in a separate thread (or even a separate process like
Chrome). This may help us to reduce the likelihood of putting the core
into an unsafe state. Because regardless of how much we try to blame
plugin writers for causing crashes, freezes, etc., the users won't care
and will blame DC++. I don't fault them either because I get pissed at
Firefox when it crashes even though I know it is a plugin since Firefox
should've prevented it in the first place.

When I was originally looking at this I assumed it would be used for
mainly plugins that affect the UI and did not realize that it was
powerful enough to affect the core behavior. However, I can see the
advantages of having a more powerful plugin system and if that's what
people want I won't stand in the way. The overall purpose of the plugin
system is to reduce the multitude of DC++  mods and if this capability
is necessary to do it, then so be it.

But I have to be adamant in calling for an event driven architecture.
Whether this uses the Speaker system or some enhanced version of it is
not as important. The point is that the core should not be calling the
pluginmanager directly, but instead it should generate an event and
notify all observers of that event. This is the observer pattern and it
allows us to decouple the plugin system from the rest of the core.

As for a pure C API, I think we should support a predetermined set of
languages to write plugins in instead of trying to make it as generic as
possible. For example, say we want to support C++ and lua only then we
don't need to worry about supporting VB or delphi. Thus if it was
possible to write a plugin system in C++ for lua and C++ (I've no idea
if that's possible, just an example), then that is the approach we
should take. I would take C++ over C if it supports the desired
languages.

On that topic, one question I had was how do non-C++ plugins utilize the
dcptr_t object types within the data structures? Most of the types
within the structs passed to the plugin callback are POD types and can
be utilized easily, but how is a pointer to, say, Client* used in a
non-C++ plugin? Don't we need to extract the useful elements from the
object being pointed to and send them as POD types?

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