Udo Richter wrote:
Martin Wache wrote:
In my opinion the method CallPluginExtension() is not needed, the same can easily done by just calling cPluginManager::GetPlugin("name")->ExtensionInterface().
The only (very minor) difference is that your call uses the first plugin of that name, while CallPluginExtension() queries all plugins of that name until one answers.
There is only _one_ plugin of any given name. So I also think that CallPluginExtension() is superfluous.
Any caller who wants to direct a service call to a particular plugin should first check whether that plugin is there, anyway. Otherwise it wouldn't know whether the request was denied because the parameters were wrong, or whether the plugin wasn't there at all.
cPlugin *Plugin = cPluginManager::GetPlugin("someplugin"); if (Plugin) Plugin->Service("someserviceid", somedata);
I think it would be nice to be able to know which plugin actually answered the request, so that following request can be sent directly to that plugin.
CallPluginExtension() and CallFirstExtension() actually return a pointer to the plugin that answered the request, or NULL if none answered.
If you're worried about speed, you could pass through a pointer to a callback function, so further communication uses the callback and not the interface.
Christian Wieninger wrote:
I think so too. Perhaps CallAllExtensions could also return a pointer to the plugin like CallFirstExtension does.
The point of CallAllExtensions() is that the call goes to all extensions, not just one. It would need a whole list of plugins to solve this.
I also think that returning a bool telling the caller whether _any_ plugin has processed the call should be enough.
Thanks again. The next release of epgsearch will support this patch, and I hope I can soon drop the currently needed #ifdef PATCH_EXTENSIONINTERFACE ;-)
I've used #if VDRVERSNUM >= 10330 || defined(PATCH_EXTENSIONINTERFACE) in the sources by purpose, so the code will be used for VDR 1.3.30 and any previous version that is patched. Why drop backwards compatibility?
Please note my suggestion regarding the names (s/Extension/Service/g) in my reply to Udo.
Klaus