[vdr] Feature request: suggestion for cPlugin

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Fri Aug 19 14:43:56 CEST 2005

Udo Richter wrote:
> Martin Wache wrote:
>>In my opinion the method CallPluginExtension() is not needed, the same
>>can easily done by just calling
> 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.


More information about the vdr mailing list