[vdr] Re: VDR Plugin System - First Step

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Stefan Huelswitt wrote:
> 
> On 10 May 2002 Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote:
> 
> >> One more thing: the value of ConfigDirectory (internal to
> >> vdr.c:main() should be available to the plugins to load specific
> >> config files.
> >
> > Making that directly available to plugins might not be a good idea,
> > because then two plugins might use the same names for their config files.
> > So I guess if we need this at all, it should be a function that returns
> > a directory name that consists of the ConfigDirectory, plus a directory
> > named like the plugin, as in
> >
> >   /etc/vdr/plugins/dvd
> >
> > (assuming that ConfigDirectory has been set to "/etc/vdr").
> > VDR could take care that this directory and all intermediate directories
> > actually exist when a plugin requests that name.
> 
> Yes, would be an option. But this would prevent that two plugins
> use the same file.

Ok, I'll make the ConfigDirectory available to the plugins.
It will be up to them to make sure there are no name clashes, though.
I still think the plugin config files should be kept in a separate
directory, so maybe it would make sense to automatically append
"/plugins" to the value of ConfigDirectory (and make sure that directory
exists, once a plugin queries it). What do you think about this?

> To clarify what my problem is: the MP3/MPlayer patch has dual
> functionality. And I don't thing that this could be build within
> on plugin. But both parts use nearly the same code and config
> files.

But these two _do_ implement different functionality, don't they?
Or will a user of the MP3 plugin *always* also want the MPlayer
plugin, and vice versa?

> It would be nice, to have more than one plugin inside a shared
> library and register all contained plugins after loading. e.g.
> have a global AfterLoad() function which would call
> RegisterPlugin() for every contained plugin.

I want to keep this interface simple, so there will be only exactly ONE
plugin per library.

> > Sounds reasonable. But I tend to completely shut down VDR if one
> > plugin returns 'false' from Start(), because this plugin might be
> > vital for further operation of VDR.
> 
> What about different failing codes? This would leave it up to the
> plugin to decide if VDR should abort or not.

Well, the user wanted that plugin, so if it fails to start, there's something
wrong so bad that the user most likely doesn't want to continue without that
plugin. Simply dropping it IMHO is not the way to go. The actual problem should
be solved and VDR then be started again.

> > BTW: you do know that plugins can store setup parameters in VDR's
> > 'setup.conf' file, right? What would these additional config files
> > be for (just curious)?
> 
> Yes, but as the setup file layout is simple, some things a
> difficult to store. And it would imply to have SetupMenu's for
> all these things, which may be even more complicated.

You don't need setup menus for all the parameters you store in VDR's
setup. Read the section "Setup parameters" in PLUGINS.html. You can have
any number of setup parameters without even implementing a setup menu
at all.

> I use a seperate config file to define different source
> directories for MP3/MPlayer files. The user can switch between
> them via menu, but have to edit the file manualy. The file could
> look like this:
> 
> /mnt/home/mp3;Remote an Master;0
> /mnt/cdrom;CDROM;1
> 
> I have now a running plugin with some basic functionality (i18n,
> main menu). Setup things have to come. I'm going to release this
> later as an example.

Version 1.1.1 brings a greatly simplified setup menu handling.

> Found some more points:
> -Each plugin should have a house keeping function which is called
> during VDR's own house keeping.

Ok, I can add that.

> -VDR shouldn't remove setup options from setup.conf which belong
> to plugins not loaded at the moment.

That's the way it is.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________