>1)Establish a policy of deleting the Plug-ins folder on a major >revision like going to 6.5. (or use Plugins6.5 to make Beta testing >easier)
I don't like the idea of deleting them, as that could cause someone to lose any manual alterations done to the plugins. There's no way (currently, at least) that slimdevices could tell what plugins are not compatible when upgrading, so it would be all or nothing. The old plugins folder could be moved to a backup folder, and then new slimdevices plugins installed into the new version of the plugins folder. Alternatively leave them there, but make it clear to the user via the installer that plugins may cause problems and should be removed/updated manually. I think that more could be done to protect the interface to plugins from within slimserver code - eg. put error handling around calls to plugin initialisation code so any startup errors are trapped and reported, disabling the plugin. As mentioned a long time ago, perhaps it's unrealistic for slimserver code to protect against every possible exception caused by dodgy plugin code, but at least attempt to trap errors propagated from known functions that will be invoked, such as sub initPlugin, Perhaps a plugin should also provide a method that returns the slimserver version (or DB schema version?) it was written for. If slimserver goes up a major version, it could automatically disable any plugins that are old. Phil _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
