Plugin api brush-up

[mherger]

There were quite a few things to be "optimized" in the plugin api. And
before kdf removed the on-the-fly loading I wanted to give it another
chance ;-). Most of the initialization needed after changes to the plugin
list should now be done in Slim::Buttons::Plugins::initPlugins().

- call webPages() even if a plugin is enabled; this allows us to remove
additional links calling webPages() (had to use addMenu() before...)

- show internet radio settings only on its own page, no longer on the
plugins page

- only cycle once through the plugins list during initialization (used to
do it up to (x^2 + 3x) times)

- the plugins parts in the settings now basically only cares about the
state of the checkboxes

- plugins can expose a web page without adding a mode to the player
(setMode(), lines(), getFunctions() aren't needed) - should update docs?

- string() isn't needed, neither (wasn't before...) -> could be removed
from MusicMagic & co.

- best of all it should add/remove plugins/screensavers correctly...


Please give this some good testing. Any comment is welcome!

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

[dean]

Michael,

This is good work. I have one other request for your "brush-up". It
would be great if plugins could express a minimum server version
level and have them not install if that version is not met.

[mherger]

> This is good work. I have one other request for your "brush-up". It
> would be great if plugins could express a minimum server version level
> and have them not install if that version is not met.

I think this is what enabled() is for. The importer plugins use the
following:

sub enabled {
return ($::VERSION !~ /^5/) && initPlugin();
}

This would be fine if initPlugin() didn't do stuff we don't want it to do
(eg. add setup groups without verifying the plugin's state). But I've
opened an other thread about that.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

[dean]

Ok, that's fine. Now we just need to use it!


On Apr 29, 2005, at 8:23 AM, Michael Herger wrote:

>> This is good work. I have one other request for your "brush-up".
>> It would be great if plugins could express a minimum server
>> version level and have them not install if that version is not met.
>>
>
> I think this is what enabled() is for. The importer plugins use the
> following:
>
> sub enabled {
> return ($::VERSION !~ /^5/) && initPlugin();
> }
>
> This would be fine if initPlugin() didn't do stuff we don't want it
> to do (eg. add setup groups without verifying the plugin's state).
> But I've opened an other thread about that.
>
> --
>
> Michael
>
> -----------------------------------------------------------
> Help translate SlimServer by using the
> StringEditor Plugin (http://www.herger.net/slim/)
>
>

[mherger]

> Ok, that's fine. Now we just need to use it!

This could be helpful with the different plugin versions moved to
subfolders... I'll have a look at this.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

[dean]

I'm already mostly done with adding versions to the plugins we ship
with the server.

Definitely recommend that version checking be added to third-party
plugins...


On Apr 29, 2005, at 8:44 AM, Michael Herger wrote:

>> Ok, that's fine. Now we just need to use it!
>>
>
> This could be helpful with the different plugin versions moved to
> subfolders... I'll have a look at this.
>
> --
>
> Michael
>
> -----------------------------------------------------------
> Help translate SlimServer by using the
> StringEditor Plugin (http://www.herger.net/slim/)
>
>

[Marc Sherman]

dean blackketter wrote:
> Michael,
>
> This is good work. I have one other request for your "brush-up". It
> would be great if plugins could express a minimum server version level
> and have them not install if that version is not met.

I'd recommend that they also not start up if there's a major version
number change; for example, a plugin specifying "6.1.1" as it's required
version should start fine on 6.1.1, 6.1.3, and 6.2.0, but fail on both
6.0.2 and 7.0.0. Most 5.x plugins broke quite a bit when installed on 6.0.

- Marc

[kdf]

Quoting Michael Herger <slim (AT) herger (DOT) net>:


> sub enabled {
> return ($::VERSION !~ /^5/) && initPlugin();
> }
>
> This would be fine if initPlugin() didn't do stuff we don't want it to do
> (eg. add setup groups without verifying the plugin's state). But I've
> opened an other thread about that.

As long as this is used as part of read_plugins, and if enabled fails then we
fails the require. This should then free up the memory, right?

-kdf

[mherger]

On Fri, 29 Apr 2005 21:15:36 +0200, kdf <slim-mail (AT) deane-freeman (DOT) com>
wrote:

>> sub enabled {
>> return ($::VERSION !~ /^5/) && initPlugin();
>> }
>>
>> This would be fine if initPlugin() didn't do stuff we don't want it to
>> do (eg. add setup groups without verifying the plugin's state). But I've
>> opened an other thread about that.
>
> As long as this is used as part of read_plugins, and if enabled fails
> then we fails the require. This should then free up the memory, right?

I think I'm hitting the limits of my english knowledge. Sometimes it's
hard to make oneself understood if it's a little complicated even in ones
mother tongue :-/. I'll try to explain it anyway.

In addPlugins() I try to verify if a plugin is loadable (getDisplayName(),
read strings, etc.). This should include enabled(). If addPlugins() fails,
it won't continue with the current plugin. If it's successfull it will add
menus, webpages, settings etc.

During this initial check I'd like to call enabled() to be sure it has all
it needs. But only check it, not initialize it. If it already creates (as
the importers do) setupGroups, protocolhandlers etc. it will do a lot that
will be done again when running addMenu, addSetupGroup etc. We therefore
will end up with double settings etc. and finally initPlugin(). Therefore
should enabled imho only be a sanity check, not an initialization.

Anybody out there understand me language? :-)

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

[dean]

The code I'm adding to ours is:

if ($::VERSION gt '6.1')

which should work as long as we don't change the version format.

On Apr 29, 2005, at 11:31 AM, Marc Sherman wrote:

> dean blackketter wrote:
>
>> Michael,
>> This is good work. I have one other request for your "brush-up".
>> It would be great if plugins could express a minimum server
>> version level and have them not install if that version is not met.
>>
>
> I'd recommend that they also not start up if there's a major
> version number change; for example, a plugin specifying "6.1.1" as
> it's required version should start fine on 6.1.1, 6.1.3, and 6.2.0,
> but fail on both 6.0.2 and 7.0.0. Most 5.x plugins broke quite a
> bit when installed on 6.0.
>
> - Marc
>