All - as part of the 7.0 goals, we want to change how SlimServer handles Plugins, focusing on installation, loading, packaging & Settings.
A high level overview exists on the wiki: http://wiki.slimdevices.com/index.cgi?SlimServer7Spec I'd like to get a discussion going so we can start writing some code and get this train moving. For some background, see http://bugs.slimdevices.com/show_bug.cgi?id=4112 Goals: * Improve the user experience of installing & configuring plugins. * Versioning plugins to ensure SlimServer stability. ---- Strategies: * Packaging of plugins: - The model that Mozilla/Firefox has is the right one. Plugins come as a single (zip) file, with some metadata which would allow SlimServer to determine plugin compatility from not only a min & max version number, but also a target platform if the plugin needs any binary components. - The actual plugin library code would be contained within a PAR file (http://par.perl.org/) inside the first zip file, referenced by the metadata file. This allows the bundling of extra libraries, both pure perl & compiled in nature. - As with the current structure, content such as HTML & images would be contained in the top level zip file. * Installation of plugins: - Plugin packages will be installed via the WebUI, and will have the following states: - Needing Installation (requires SlimServer restart) - Installed & Enabled - Installed & Disabled - Needing Uninstallation (requires SlimServer restart) * Plugin Initialization: Currently Slim::Utils::PluginManager calls Plugin::YourPlugin::init(), and then looks for some well named functions to add things like web pages, settings, screensavers. That functionality is backwards. The plugin should actively register any components that it has during the initialization. * Plugin Settings / Options: As part of the 7.0 work, the Server & Player Settings pages are being overhauled. Previous to this, there was a giant (unmaintainable) hash table in Slim::Web::Setup & awkward page building system. 7.0 is getting rid of all of that, and moving to a cleaner, HTML + controller driven model. This allows flexibility for the designs of settings pages, finer grained field validation and a nicer user experience. This will require changes to your plugins however, and will likely be the hardest part of all this work. Each plugin will have it's own settings page (drop down), which will remove the clutter from the "Plugins" page. The validation areas are still being worked out. * Logging: Already in the 7.0 codebase is Log::Log4perl, which is a fantastic, fine grained logging system. The shipped SlimServer plugins show how one can use it, this code will likely stay as-is. Please migrate from the old msg()/errorMsg() code. * SlimServer shipped plugins: We'll be moving the "plugins" that we ship, such as the iTunes importer, RSS reader, etc into the Slim/Plugins/ directory. * What this "change" probably isn't. Because of the flexible nature of perl, and the creativity of our community we've never had a strict API in the "you can only access these methods" sort of way. There has been some talk of defining a real Public API that plugins can use. Unfortunately I think that is beyond that scope of what I originally had in mind. However, if we can come up with places in the SlimServer code where well documented hooks can be called, I'm all for that. I'd love to see plugins register themselves with SlimServer saying "Please run me when you call hook player.mainMenuList". Which bleeds into changes I'd like to see such as bug: http://bugs.slimdevices.com/show_bug.cgi?id=3997 Once we have things like that, providing hooks become much easier, either through subclassing or different method resolution mechanisms like C3 - http://search.cpan.org/dist/Class-C3/ At the same time that I want to limit what plugins can do in order to maintain stability of the server, I don't want to stifle creativity. So I'd love to talk about finding some middle ground. * Backwards compatibility: As a result of the packaging changes, and to some degree the Settings changes, backwards compatibility with existing plugins as they are today will not be maintained. At a minimum, the plugin will need to be packaged with metadata and some initialization changes will need to be made. Additionally, if your plugin makes use of web Settings, it will need to be updated. ----- I'll be cross posting this in the Plugins & Developer forums, but would really like to see the discussion happen in Developers. Thanks -- Dan Sully ------------------------------------------------------------------------ Dan Sully's Profile: http://forums.slimdevices.com/member.php?userid=1 View this thread: http://forums.slimdevices.com/showthread.php?t=30148 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/plugins
