<?sphp $this->text('pagetitle') ?>
 
Home of the Squeezebox™ & Transporter® network music players.

Plugin API

From SqueezeboxWiki

Revision as of 07:11, 23 June 2010 by Soulkeeper (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Initial thoughts (Some paraphrased from bug 4112):

Contents

Installation / Packaging:

Look at Firefox for inspiration. zip file with install.xml file which contains metadata such as name, min & max slimserver version the plugin is compatible with, url for updated version of the plugin, url for information on the plugin.

Min & Max versions specifications will help with the server crashing, as we won't load bad plugins in the first place.

Additionally, the plugin itself should be another zip file within the zip file, possibly packaged with PAR::Dist

Plugins should have the following states:

    • Pending Installation after server restart.
    • Installed
      • Enabled
      • Disabled
    • Uninstalled after server restart.

Directory Structure:

TODO

Code Structure:

There should be a plugin base class - possibly Slim::Plugins::Base ? Which plugin should inherit from to provide base functionality.

Plugins should be as object oriented as they can (unless working around non-OO things in core, such as "button modes". So use Class & Instance methods instead of Plugin::Foo::function() calls.

Plugins should also add themselves to menus they need to be in, specifically in the button code. Currently ::PluginManager calls into Slim::Buttons::Home::addSubMenu() - which is busted. The plugin should make that call (or we should have a better API for doing so). The plugin base class can help with this as well.

Setup:

Plugins need to be able to specify webpage & setup handlers. The large setup hash is going away, so Plugins will need to do a little more work. Some of this work can be alleviated with proper inheritance from the Plugin base class.

HTML will & should be custom, allowing plugin specific UI to best serve the user.

Strings:

Plugins should move inline strings to strings.txt as defined by the directory structure above.

Prefs:

Plugins should not store their data in the main pref file. Store data in the database, or in a plugin specific pref file?

Also, an automated means of uninstalling a plugin should be created either by the installation process or else required of all plugins so that they clean up any tables created in the database, any files installed in the server tree, and any settings and data stored in prefs files.

Slim Devices shipped Plugins:

Have moved to Slim/Plugin/