Plugin Idea: Export/Import Plugins

[stuckless]

First off, I don't have time to do this myself, or I would, but here's the basic idea.

The new plugin system is amazing... I love it... I love the people that made it happen. But, if you are like me, you are spending time adding your plugins... and configuring them, but then a new release of SageTV comes out, and you start the installing and configuration process all over again.

Some people probably just upgrade in place, but I always install a new Sage build and then apply and configure everything. In most cases I even blow away my Wiz.bin.

The idea behind the Export/Import plugin is that in your current configuration you select to Export your plugins. What this does, is create a DeveloperPlugins.xml (not sure if that's the correct filename or not), where a new plugin is added called, "Your Configuration" (or whatever) that simply depends on every plugin that you have installed.

Later when you get a new sage build, you copy the DeveloperPlugins.xml to the new sage install dir, start sage, and go into Plugins, and you should see a plugin in there called, "Your Configuration". When you select to install it, it will install every plugin that you had installed on your previous build.

To extend on the concept, it would be nice if the exported plugins, could also export their configurations as well. This can be done as well, but would require some extra java/stv coding whereby the PluginAPI is used to get a list of the plugin properties and the are retrieved and stored in an external properties file(s). The Import/Export plugin could potentially read those files and call the appropriate PluginAPI to set those properties, by allowing the user to click an "import configuration" button, etc.

The side benefit of something like this, is that it could be used to informally share your configuration (installed plugins and/or configuration) with other users. For example, lets say you have a cool setup using Jetty, Serenity, UPnP browser, etc, etc, you could export it, and post it somewhere for someone else to download and then "Import" using the Import/Export plugin.

These "configurations" are basically faux packages that are simply place holders that force a bunch of dependent plugins to be installed.

Anyways, this is just an "idea"... feel free to comment on it, extend, etc. I can't actually do this myself, but I think it would be a useful plugin for some people

[PLUCKYHD]

It is a good idea i agree (1,2,3 not it....)

For reference is is SageTVPluginsDev.xml if anyone tries it.

This would be a bit tricky with external properties (the entire thing would be a huge learning curve) but is very very doable. I also would like to see someone make something like this as I agree it would be usefull before even with the great plugin system browsing around and adding all your plugins one by one after a fresh install is a bit of a pain I agree.

It also makes we wonder though how on earth would you get external property files backed up (especially if they are not in the default sagetv folder which is the case with upcoming SMM). Maybe I am missing a entire aspect of the plugin api where I can let others know what prop files I am using. Regardless great idea.

[stuckless]

Originally Posted by PLUCKYHD

This would be a bit tricky with external properties (the entire thing would be a huge learning curve) but is very very doable. I also would like to see someone make something like this as I agree it would be usefull before even with the great plugin system browsing around and adding all your plugins one by one after a fresh install is a bit of a pain I agree.

It also makes we wonder though how on earth would you get external property files backed up (especially if they are not in the default sagetv folder which is the case with upcoming SMM). Maybe I am missing a entire aspect of the plugin api where I can let others know what prop files I am using. Regardless great idea.

I think that with the new plugin api, PluginAPI.GetPluginConfigSettings(Plugin), would return a list of properties that you are using... That's not to say that they are all in the same file, or even in a file. The nice thing about the PluginAPI abstraction is that it's up the implementation class to determine where and how they are stored. In the sagex-api AbstractPlugin class, the default implementation is to use Get/SetProperty, but you can provide your own IPropertyPersistence implementation to set/get the properties to another location. (sagex provider ClientPropertyPersistent and ServerPropertyPersistence).

[GKusnick]

Using dependencies to create an empty umbrella plugin that captures your current plugin state is a clever idea. This could be a handy way to configure multiple clients, although I'm not sure I personally would have much use for it, since I don't have that many clients, and I always upgrade my SageTV installation in place, to preserve current settings.

I do see a couple of potential problems:

There's no guarantee your current plugin state still exists in the online repository. Plugins may have been withdrawn, or superseded by newer versions that perhaps aren't completely compatible, or the dependency landscape may have shifted in such a way as to make the aggregate dependencies of all your current plugins impossible to satisfy.

There's also no guarantee that you'll be able to capture the complete configuration of any given plugin through the PluginAPI. Any given call to GetPluginConfigSettings() may not return the complete list of settings, but only those settings the plugin itself deems relevant to its current state. So for instance it may choose not to show you detailed option settings for feature X unless X is enabled. Or the plugin may partition its settings into several pages, where you must first choose which page you want to see before it shows you the settings on that page. In general it's not going to be possible to get all the settings this way or even to know whether a plugin has hidden some settings from you.

Also note that STVI plugins cannot have an ImplementationClass and therefore cannot use the PluginAPI config machinery (at least not without a separate Standard-type helper plugin). Since STVIs can call Get/SetProperty directly from widget code, the likelihood is that their settings will be invisible to your PluginAPI-based config analyzer.

[stuckless]

Originally Posted by GKusnick

Using dependencies to create an empty umbrella plugin that captures your current plugin state is a clever idea. This could be a handy way to configure multiple clients, although I'm not sure I personally would have much use for it, since I don't have that many clients, and I always upgrade my SageTV installation in place, to preserve current settings.

The idea of "umbrella" plugins came to me from using linux package managers. You can selected to install a "layer" which is simply an empty package that depends on everything for that layer. It's a quick way to install a lot of related plugins.

I think that over time, whether or not this gets built or not, we'll probably see some of these umbrella plugins showing up in the repository.

I do see a couple of potential problems:

There's no guarantee your current plugin state still exists in the online repository. Plugins may have been withdrawn, or superseded by newer versions that perhaps aren't completely compatible, or the dependency landscape may have shifted in such a way as to make the aggregate dependencies of all your current plugins impossible to satisfy.

There's also no guarantee that you'll be able to capture the complete configuration of any given plugin through the PluginAPI. Any given call to GetPluginConfigSettings() may not return the complete list of settings, but only those settings the plugin itself deems relevant to its current state. So for instance it may choose not to show you detailed option settings for feature X unless X is enabled. Or the plugin may partition its settings into several pages, where you must first choose which page you want to see before it shows you the settings on that page. In general it's not going to be possible to get all the settings this way or even to know whether a plugin has hidden some settings from you.

Also note that STVI plugins cannot have an ImplementationClass and therefore cannot use the PluginAPI config machinery (at least not without a separate Standard-type helper plugin). Since STVIs can call Get/SetProperty directly from widget code, the likelihood is that their settings will be invisible to your PluginAPI-based config analyzer.

Yeah... i totally agree with all of those problems. The plugin configuration was a long shot, and I didn't even think about the stvi stuff.

given the unreliable nature of backing of a plugin configuration, i think it should be dropped from the scope actually. That then simplifies what this would need to do... which is simply create an xml of the installed plugins.

You raised a good about about obsolete plugins. What does the plugin manager do when they are obsoleted and no longer in the repsository. Do you see a message against your installed plugin that tells you that the developer has removed it?

[Jabroni]

I really like this new plugin System... but I think there is still room for improvement


Here are some sugguestions:

* A way to see/post a changelog for the plugin
* A way to have a repository of all revision of the plugins, and be able to 'rollback' from the GUI
* A plugin rating system (so it would require users to submit their rating), or maybe 'download popularity
* A category system (more like the apple appstore)


Now for the forums, I think it would be nice if the devs used the same convention of categoring for the forum, so instead of having a forum with all the threads, you can look directly on the part. Another good idea is to give some naming tips to the comunity to start a thread (ie (Type) - (Name) - (Latest Version)

Anyone with me with these??

Just my 2 cents

[LehighBri]

One additional item I'd like to request re: the amazing new plugin system:

* Add ability for plugin updates to trigger the creation of a system message that says a plugin update exists, AND, when I click on that system message, it asks if I want to update it

(or maybe this exists already and I just don't have it set up...)