Plugin installer - demo now available in 7.3 for test

[Triode]

7.3 as of svn 23770 includes the ability to download and install plugins from a list which is maintained in xml based respositories. There's a long discussion on this on another thread, but I think it is now complete enough to ask plugin authors to look at it and feedback whether it is useful and how it can be improved. The only serious restriction at present is that it requires the server to be manually restarted after you install/upgrade/remove a plugin.

The aim is that slimdevice.com will host a centrally maintained xml repo file which servers fetch and use to build a list of available plugins. In addition to this individual plugin authors can host their own repo xml file and distribute the url for individual users to add to their server (settings - advanced - extension downloader "additional repositories"). At present there is no central repo, but you can trial it by adding the following url to the "addtional repositories" setting:

http://svn.slimdevices.com/7.3/trunk/server/Slim/Plugin/Extensions/demorepo.xml?view=co

This should show 6 plugins for installation on the web setting page. Of these "Alien BBC" and "Plugin Test" are real plugins and be able to be installed. (Alien is the full AlienBBC minus mplayer)

These should show:
- how to host a plugin and publish it via an xml repo including localisation for the title and a short description with an optional link to your web page for more info
- how to make multiple versions of a plugin available for different platforms - Alien has a unix/mac version and a windows version
- how to include more than one version of a plugin (although the expectation is that when a new version is available the old version will be removed from the xml repo - Test Plugin v1 can upgraded to Test Plugin v2 though.)

(the repo file also includes some additional wallpapers for jive. These are described elsewhere but use the same mechanism.)

Anyway the reason for the post was to ask plugin authors to take a look at it and see if it meets all reaquirements. Ideally I'd like to get enough feedback to leave it as on by default in 7.3 and perhaps lobby to set up the default repo at slimdevice.com. Even without this, it should be useful for plugin authors who want to manage their own repo file.

What do you think?

Adrian

[erland]

It seems to add an extra directory level when unzipping the plugins. For example, my TrackStat plugin built with the PluginBuilder will be unzipped as:
Cache/InstalledPlugins/Plugins/TrackStat/TrackStat/lib/Plugins-TrackStat-Plugin.par
Instead of:
Cache/InstalledPlugins/Plugins/TrackStat/lib/Plugins-TrackStat-Plugin.par

The PluginBuild builds the plugin zip so it contains the plugin name as the top directory inside the zip file. The result is that I can't build the plugin with PluginBuilder if it should work with the new plugin installer. I would prefer if the plugin installer didn't add an extra directory level since it would mean that I can distribute the same zip file for plugin installer and also for manual installation.

During development it would be nice if there was a way to force it to re-read the repository xml files, it's a bit frustrating when you create the XML files and need to shutdown SqueezeCenter and clear the cache to refresh the information. Maybe saving the repository list also could read a fresh copy of the repository xml files or as an alternative just add a refresh button to the page.

I wonder if it would be preferable if the "More information" link was opened in a new window ?
At the moment you lose the section drop list at the top when you hit this link which means that you can't get back without using the browser back button.
I think I typically are going to want to link to pages like these:

http://erland.isaksson.info/download/do/viewapplication?name=slimserver-trackstat

http://wiki.slimdevices.com/index.php/TrackStat_plugin

And none of these looks pretty good when they are fitted into the same window.

By the way, it is possible to use <br> in the desc element to accomplish a multi row description. This is great for me because it means I can put the change log in the desc element, but I thought I mention it anyway in case it is a security risk.

For other third party developers that tries this, please notice that your plugin won't appear in the list as long as you have it installed in the old "Plugins" directory.

I assume the plugin installer is going to be integrated in the standard "Plugins" tab in "SqueezeCenter Settings" ?
It would at least be be good if there were a link available to it from the standard "Plugins" tab.

[Triode]

Plugin installer - demo now available in 7.3fortest

> It seems to add an extra directory level when unzipping the plugins. For
> example, my TrackStat plugin built with the PluginBuilder will be
> unzipped as:
> Cache/InstalledPlugins/Plugins/TrackStat/TrackStat/lib/Plugins-TrackStat-Plugin.par
> Instead of:
> Cache/InstalledPlugins/Plugins/TrackStat/lib/Plugins-TrackStat-Plugin.par

Ah - yes I am afraid it assumes the zip has no folder information in it
(I've never used plugin builder for distributing plugins..). I want to make
sure the downloader decides where files go, but perhaps we can get it to
install from the zip file more intelligently and ignore path info if it is
there. Let me look at this.

> During development it would be nice if there was a way to force it to
> re-read the repository xml files, it's a bit frustrating when you
> create the XML files and need to shutdown SqueezeCenter and clear the
> cache to refresh the information. Maybe saving the repository list also
> could read a fresh copy of the repository xml files or as an alternative
> just add a refresh button to the page.

You should be able to just wipe Cache/FileCache while developing. Its
cached for 5 mins as all the xmlbrowser hashes are - I'd prefer to avoid
have a user button for forcing this if possible.

> I wonder if it would be preferable if the "More information" link was
> opened in a new window ?
> At the moment you lose the section drop list at the top when you hit
> this link which means that you can't get back without using the browser
> back button.
> I think I typically are going to want to link to pages like these:
> http://erland.isaksson.info/download...rver-trackstat
> http://wiki.slimdevices.com/index.php/TrackStat_plugin
> And none of these looks pretty good when they are fitted into the same
> window.

Yes probably.

> By the way, it is possible to use <br> in the desc element to
> accomplish a multi row description. This is great for me because it
> means I can put the change log in the desc element, but I thought I
> mention it anyway in case it is a security risk.
>
> For other third party developers that tries this, please notice that
> your plugin won't appear in the list as long as you have it installed
> in the old "Plugins" directory.

Yes - there is a log warning for this, should it show up as an error
message? Its a protection as its not possible to remove the old plugin.
Should we have additional items in the list of plugins which can't be
installed and should be manually removed first?

> I assume the plugin installer is going to be integrated in the standard
> "Plugins" tab in "SqueezeCenter Settings" ?
> It would at least be be good if there were a link available to it from
> the standard "Plugins" tab.

Well at present its in a plugin as it was not intended to make it into 7.3
and Michael suggested we include it as "experimental" in 7.3 as there is
only one week to finish features for 7.3. I fully expect to merge it with
the standard plugin tab later on assuming it works for people and plugin
authors/users find it useful. So any support you can give in confirming its
usefulness is welcome.

The only other major issue is restarting the server - I can't see an easy
cross platform way to automatically restart the server and follow the normal
process on each platform. I'd like to be able to do this but can't see a
way at present - any suggestions?

[Triode]

Plugin installer - demo now available in 7.3fortest

>> It seems to add an extra directory level when unzipping the plugins. For
>> example, my TrackStat plugin built with the PluginBuilder will be
>> unzipped as:
>> Cache/InstalledPlugins/Plugins/TrackStat/TrackStat/lib/Plugins-TrackStat-Plugin.par
>> Instead of:
>> Cache/InstalledPlugins/Plugins/TrackStat/lib/Plugins-TrackStat-Plugin.par
>
> Ah - yes I am afraid it assumes the zip has no folder information in it
> (I've never used plugin builder for distributing plugins..). I want to
> make
> sure the downloader decides where files go, but perhaps we can get it to
> install from the zip file more intelligently and ignore path info if it is
> there. Let me look at this.
>

Erland - can you try this now - it should ignore the extra folder
information.

[sebp]

The only other major issue is restarting the server - I can't see an easy cross platform way to automatically restart the server and follow the normal process on each platform. I'd like to be able to do this but can't see a way at present - any suggestions?

I didn't look at how SC startup was implemented, so this is just a suggestion :
It's a common thing with UNIX daemons to map the "hang up" (SIGHUP) signal to reload the daemon's configuration. Signals are POSIX compliant, so they should work well with Windows. Rather than really restarting the SC server, all you'd need would be to send the SC process a signal (with the "kill" system call), which would be handled by a callback function ($SIG{'HUP'} = \&reloadSC() which would call proper code for reloading configuration (or maybe would set a global variable, call the shutdown function that would call itself the startup function if this global's set).

[Triode]

I didn't look at how SC startup was implemented, so this is just a suggestion :
It's a common thing with UNIX daemons to map the "hang up" (SIGHUP) signal to reload the daemon's configuration. Signals are POSIX compliant, so they should work well with Windows. Rather than really restarting the SC server, all you'd need would be to send the SC process a signal (with the "kill" system call), which would be handled by a callback function ($SIG{'HUP'} = \&reloadSC() which would call proper code for reloading configuration (or maybe would set a global variable, call the shutdown function that would call itself the startup function if this global's set).

Unfortunately we want to do more than just re read the config file, we want to remove perl modules that were already loaded and load new ones. Given the flexibility plugins have I think we need to restart the server from scratch and hence need some way to do this. [at present its the user!]

[peterw]

Unfortunately we want to do more than just re read the config file, we want to remove perl modules that were already loaded and load new ones. Given the flexibility plugins have I think we need to restart the server from scratch and hence need some way to do this. [at present its the user!]

Which might just mean building a "watchdog" supervisor process. The watchdog would be responsible for spawning squeezecenter.(pl|exe), mysqld, mDNSResponder, etc. and would keep running. *Restarting* SC7 would mean sending SIGUSR1 or something to SqueezeWatchdog, which would then kill the mysql/mdns/sc7 procs and start them afresh. Stopping SC7 would mean stopping those procs and the supervisor/watchdog, too.

[Triode]

Plugin installer - demo now available in 7.3fortest

> Which might just mean building a "watchdog" supervisor process. The
> watchdog would be responsible for spawning squeezecenter.(pl|exe),
> mysqld, mDNSResponder, etc. and would keep running. *Restarting* SC7
> would mean sending SIGUSR1 or something to SqueezeWatchdog, which would
> then kill the mysql/mdns/sc7 procs and start them afresh. Stopping SC7
> would mean stopping those procs and the supervisor/watchdog, too.

The complexity is that this would need to be different per target platform.
For Debian it probably works now by just exiting squeezecenter, as there is
a wrapper script which will restart it. But for other platforms the same
does not apply although it could - but not in 7.3 timescales...

[peterw]

The complexity is that this would need to be different per target platform.
For Debian it probably works now by just exiting squeezecenter, as there is
a wrapper script which will restart it. But for other platforms the same
does not apply although it could - but not in 7.3 timescales...

Exactly -- I have zero understanding of SqueezeTray on Windows, or how the Windows services for SC are set up. 7.4, maybe, but 7.3, no way. Too big a change to attempt this late. But I think it's a worthy long-term goal.

[erland]

> For other third party developers that tries this, please notice that
> your plugin won't appear in the list as long as you have it installed
> in the old "Plugins" directory.[/color]

Yes - there is a log warning for this, should it show up as an error
message? Its a protection as its not possible to remove the old plugin.
Should we have additional items in the list of plugins which can't be
installed and should be manually removed first?

Might be a good idea, I think people are going to ask why their favorite plugin doesn't appear in the list.

>> It seems to add an extra directory level when unzipping the plugins. For
>> example, my TrackStat plugin built with the PluginBuilder will be
>> unzipped as:
>> Cache/InstalledPlugins/Plugins/TrackStat/TrackStat/lib/Plugins-TrackStat-Plugin.par
>> Instead of:
>> Cache/InstalledPlugins/Plugins/TrackStat/lib/Plugins-TrackStat-Plugin.par
>
> Ah - yes I am afraid it assumes the zip has no folder information in it
> (I've never used plugin builder for distributing plugins..). I want to
> make
> sure the downloader decides where files go, but perhaps we can get it to
> install from the zip file more intelligently and ignore path info if it is
> there. Let me look at this.
>

Erland - can you try this now - it should ignore the extra folder
information.

It now works perfectly as far as I can see, thanks.

[mherger]

Plugin installer - demo now available in 7.3 fortest

> Exactly -- I have zero understanding of SqueezeTray on Windows, or how
> the Windows services for SC are set up. 7.4, maybe, but 7.3, no way.

We have been discussing automatic restarts before. But it's harder to do than it first looks. Even SqueezeTray won't help us on Windows, if the user is running SC as a service. And I doubt users want even more tasks running in the background.

--

Michael

[gharris999]

> Exactly -- I have zero understanding of SqueezeTray on Windows, or how
> the Windows services for SC are set up. 7.4, maybe, but 7.3, no way.

We have been discussing automatic restarts before. But it's harder to do than it first looks. Even SqueezeTray won't help us on Windows, if the user is running SC as a service. And I doubt users want even more tasks running in the background.

--

Michael

I have a solution to this (getting SqueezeCenter to restart itself as a service on windows) that I'll put up here later today when I get home and can post the code.

[mherger]

Plugin installer - demo now available in 7.3 fortest

> I have a solution to this (getting SqueezeCenter to restart itself as a
> service on windows) that I'll put up here later today when I get home
> and can post the code.

That would be great!

--

Michael

[gharris999]

Eh. I shouldn't have gotten your hopes up. What I should have said is that I've figured out a horrible kludge that works. I've been trying to add a "Restart SqueezeCenter" feature to the SrvrPowerCtrl plugin. On windows, I find that its very hard to spawn a process from SqueezeCenter that can successfully restart SqueezeCenter as a service. The service will start and then die, complaining that another instance is already running, even though the previous instance has already been stopped. My solution (a.k.a. kludge) is to use the windows "at" command to schedule the restart a minute or two in the future. Hardly ideal, I know, but it works reliably.

Take a look at this: http://www.hegardtfoundation.org/slimstuff/srvcctrl.zip

In that zip is a cmd script that I'm working on that will restart SqueezeCenter, either as a user app or as a service. Included is a C utility and source code I put together for controlling windows services. On windows, the plugin schedules this script via the "at" command. One could, if one knew one was dealing with SC as a service, skip the script and just schedule a call to srvcctrl via a system call:

c:\windows\system32\cmd.exe /C start /B at.exe hh:mm srvcctrl.exe -w 120 restart squeezesvc

..or some such.

I think that it might be time to start thinking about making squeezetray a C app. A lot of windows stuff that you might want to do with squeezetray is easier in C than in perl....like this service control code.

[Mark Miksis]

Hi Triode, nice work. I have the following comments:

- Sometimes the Applet Installer menu item disappears from the SBC and can only be brought back with a reboot. I don't think I've seen this yet with r3253 so it may be unrelated to your work and already fixed.
- Sometimes the Applet Installer window appears empty when first navigated to. I assume this delay is due to fetching and parsing the XML file. It's only a few seconds, but experienced SBC users could still see an empty window and navigate away before anything shows up. I suggest either caching the contents so they can always be displayed or use a spinny while it's downloading.
- Applets are all selected by default. They should probably be unselected (like the plugins).
- I understand the reason for it, but I really don't like the idea of listing multiple versions of a plugin. This is great for folks like us who regularly test beta versions of SC and plugins. For the average user who only ever runs the stable version of SC, this only creates clutter. All he really cares about is getting the latest stable version of a plugin that works with the version of SC he is running. If you don't want to remove this feature, I'd suggest making it a default-off option.
- There should probably be a mechanism to reconcile what happens when multiple repos have the same plugin or applet. I'd suggest that the most recent version is only used regardless of repo. If multiple repos claim to have the same version, use the one from the first listed repo.
- It seems like the plugin installer stuff on SC should be integrated into the Settings->Plugins page instead of having it's own page, but I'm not sure what this would look like.

Please take this all as constructive feedback :-)