Comment 30 for bug 587597

Revision history for this message
Crise / MW (markuwil) wrote : Re: Plugins support

The calls to pluginmanager return if they are true, because that implies plugin handled that event for us, ie. we don't want core doing anything about that particular instance of it anymore.

I agree that the plugins should not be given the possibility to put the core into an unsafe state, however, if we prevent that what can plugin do at that point anymore?

Take a simple example... if plugin wants to do something when user writes "/foo arg .... narg" to some chat... we can't have the core let it send the original text user inputted anymore, especially if the command invoked chat related action. It's really a simple catch and block (filter) based system.

About extensibility, there is registerMessage, registerRange and seekMessage to use... and you can also add constants to plugindefs enums below the *_USER values, provided they don't interfere with existing ones (also the *_USER constants do not have to be the same for all implementations, ie. they can be moved out of the way, since plugins shouldn't really use them directly they are just base values for the aforementioned message register functions). The createHook, destroyHook, setHook unHook and callHook (now in PluginApiImpl) are also usable by the plugin host just as they are to a plugin.

So to add a hook you would do something like:
id = PluginApiImpl::registerMessage(HOOK_ID, "ldcpp.DummyHook")
hook = PluginApiImpl::createHook(id, HOOK_EVENT, ...);
PluginApiImpl::callHook(id, ....);

And for plugin to subscribe to this:
id = dcpp->seek_message("ldcpp.DummyHook");
hook = dcpp->set_hook(id,...);

(Above written on the spot, so mistakes possible, error checking omitted)

About the plugin events being asynchronous, and listeners... it already uses some listeners when feasible, ie. plugin doesn't need to be able block the event. And suffice to say it is already causing me a headache as it is when it comes to creating a plugin... since dcpp thinks it is ok to call ClientDisconnected to clients when ClientConnected hasn't necessarily been fired for that client... and it is not ideal for a plugin.

To be continued...