linuxdcpp-team team mailing list archive

[Jacek Sieka <587597@xxxxxxxxxxxxxxxxxx>]

For now, I'd say it's ok to call the pluginmanager directly - eventually
it is probably the Speaker that should be extended so that an observer
can halt further processing of the event in which case the pluginmanager
would use that to suspend execution. I agree that an observer-based
solution would be nice but supplying that level of indirection requires
non-trivial work. The most probable way forward here is to have pre
/post-events where the pre events allow control while post events remain
read-only. Until that happens, I see no alternative to direct calls.

As far as affecting the core goes, in this patch there are well-defined
points where the core is being manipulated by the plugins, so those
points should eventually be hardened against reasonable abuse. Read-only
plugins have equal opportunity to do damage whether they affect the core
or not (null pointer writes...?), but leaving out the ability to modify
core behavior will lead to plugin authors resolving to hacks or doing
mods, neither of which would be desirable according to the state goals
of a plugin system.

I'm not entirely comfortable with the api taking locks, but the solution
to that issue is to simplify the dc++ threading model which is outside
the scope of this patch and will have to be addressed later.

Regarding c vs c++, a c api can generally be consumed without writing a
wrapper while c++ always requires a wrapper. On the other hand, as
steven points out, there's no real benefit in supporting more than c++
and a scripting language (lua or javascript probably since these are to
my knowledge the only popular ones that lend themselves to easy
embedding). There's the issue of binary compatibility between releases.
I don't think we need to maintain binary compatibility between compilers
but we should strive to be compatible between dc++ releases (since most
windows users download binaries...) so we can only use a subset of c++
(I think qt has a good document somewhere with reasonable guidelines...)
in order not to change the layout of objects etc - in other words a vote
for c++, but not the full glory.

Now, to the implementation =)

* Memory: 
I don't like the memalloc bits - each entity should manage its own memory. The node that allocates memory should also deallocate it and if any data needs to live past the call it should be copied.

* Usage of event ids/enums: 
This is practically a reimplementation of the win32 message loop which is a pain in the ... to work with. Examine any win32 wrapper and you'll see that they try to hide it as well as is possible...Also there's a high probability of hook id clashes around EVENT_USER if plugins start making use of intercom... instead, I think it would be better with something akin to COM / IDL... small structs with function pointers (virtual functions maybe?) that define an api for a specific part. Something like dccore but for each part - for example a queue api would look something like:

struct QueueApi {
void (*add_item)(...);
void (*remove_item(...);
void (*set_priority)(...);

void (*on_item_added)(CallbackType proc);
...
};

or possibly:
struct QueueApi {
virtual void add_item() = 0;
...
};

DCCore would then have functions to associate guid's with api implementations (and get an implementation based on guid), so the core could provide some implementations for queue, clients etc (basically one for each section of tagHookEvent)...also, gui/platform specific parts could be registered by the gui's without letting the core know about platform specifics since the struct containing the definitions for a particular guid would be defined in a platform specific header. As long as these structs only grow at the far end, newer versions are backward compatible retaining the compatibility property of message loops while allowing the compiler to do at least rudimentary static checks and doing away with the global nature of message id:s...
Basically, dccore becomes a registry of other dccore-like structs each identified by a name/guid that others can query for implementations. Whether these come from a plugin or dc++ itself doesn't matter really so the overloadability is retained...

* Guids:
I'm not a big fan of guids - strings or fourcc's spring into mind as friendlier alternatives (if you really intended guids, or uuids as they're called nowadays)

* Api versions
The current approach with current version and compatible version is fine - possibly I'd just use an int for simplicity (what semantics would you attach to 1.0 vs 1.01 vs 2.0 other one is newer than the other?) and perhaps version each part separately (each struct in the above example). In other words, dccore would have it's own version, queueapi it's own, etc.

That's enough for a start I think =)

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/587597

Title:
  Plugins support

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.