Quoting Phil Meyer <[EMAIL PROTECTED]>:
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.
already there. 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,
again, already there. and yes, already mentioned.
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.
see enabled(), plus several other methods have been used in the past depending on what made the plugins obsolete. Ultimately, it must be the responsibility of the user and the author as the final line of defense. As has already been provne, there is nothing that can really stop an author from writing around any type of protection and leaving everything vulnerable. It is not feasible to eval every line of code, mor would it be fun for plugin fans to have the API cut back to limit the abilities of plugins.
-kdf _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
