Which plugins should we include as core plugins, if we were to auto-install plugins?

[stuckless]

The more I think about this, the more I think that we don't really need to auto-install any plugins, but maybe what we need is to create some pseudo plugins that simply auto-installs plugins that "most" people would use when setting up a sagetv server for the first time. In linux (Ubuntu) their package manager has the concept of "layers", which is just a plugin that simply depends on a bunch of other plugins, so when you install it, you get a bunch of plugins without having to manually go and find each one separately. I think that we should use the plugin system and do this for SageTV.

So the question is what are the layers that we should have... and which plugins should be included into those layers.

Here's my take...

AAL01 - Base Layer
- sagex/sagex-services
- SageTV Web UI
- SageTV Mobile UI
- Comksip with Comskip UI
- youtube plugin
- upnp plugin

AAL02 - Fanart Layer
- Base Layer
- BMT Web UI
- phoenix-api/phoenix-core
- CMT (complimentary metadata tools)
- Fanart plugin for default STV (forget the actual plugin name, but I'm sure there is one)

AAL03 - Gemstone Layer
- Fanart Layer
- Gemstone UI

AAL04 - Phoenix Layer
- Fanart Layer
- Phoenix UI (Phoenix 3?)

BTW, the naming of AAL## is just to ensure that these plugins would be listed at the top

The goal here would be that after sagetv server is installed, you can easily go into the plugins and go to the UI section, and select which "layer" to install, and it will then pull in all the other required plugins.

We could still have a mechanisn to auto-install plugins on startup, but, I thinking this is more flexible, and it allows for a clean install, and then users can easily just pick a layer.

The default STV configuration wizzard could be modified to ask the user which "Layer" they want to install, with the option of "none" as well.

So the more I think about it, I think this is just a set of plugins that a defined as layers, and the the default STV, during configuration, just asks the user what they want to install. Nothing really needs to change on the core server code.

[SageWizdom]

This is a great thought. Is the idea that AAL3 would auto install all the below layers?

[jusjoken]

I like the concept. It basically can be utilized Out of the Box as you can write a plugin right now that just lists dependencies and will then cause SageTV to install those dependencies as well as their dependencies and so on just by installing this new Layer plugin.

With a few creative developers doing a small portion this could be taken a step further....

• update the core with a new plugin type called "Layer" or "Package"
• update the core STV file to support this new type as a new tab in the Plugin Manager so these are all shown together and not dependent on naming
• update the core STV so the install wizard lists these new "Layers" or "Packages" as an option to install at the end of the wizard.

It may also not be too big a stretch to provide a function in the plugin manager to "Save" your current installed plugin list as a new local "Layer" or "Package" and put it in a file called "SageTVPluginsMyPlugins.xml" and then update the core to recognize this file similar to the "SageTVPluginsDev.xml" file which would then list this "MyPlugins" in the plugin manager for easy install of your complete list of plugins. You could copy this file elsewhere for future installs too.

k

[tmiranda]

I love the idea. I'd add the Schedules Direct plugin to the base as a PVR without guide data is not very useful.

If nobody else steps up to "own" the SD plugin I'll consider taking on that role.

[Fuzzy]

Originally Posted by tmiranda

I love the idea. I'd add the Schedules Direct plugin to the base as a PVR without guide data is not very useful.

If nobody else steps up to "own" the SD plugin I'll consider taking on that role.

I think there would be an issue with auto-installing the SD plugin at this time. I think it ends up disabling the built-in EPG. That, and we really need to make a UI MOD plugin for it to move the configuration INTO the UI instead of dependent on the web UI.

[tmiranda]

Originally Posted by Fuzzy

I think there would be an issue with auto-installing the SD plugin at this time. I think it ends up disabling the built-in EPG. That, and we really need to make a UI MOD plugin for it to move the configuration INTO the UI instead of dependent on the web UI.

I didn't realize that, seems this will need more thought. My goal would be to make it very easy and as automatic as possible. Maybe on the first launch we can check to see if there is a key installed and if not give the user the option to enter one, or install the SD plugin?

We need to make Sage easy for the first time user. Most first timers will not want to end up searching the forums to get it up and running.

[stuckless]

Originally Posted by SageWizdom

This is a great thought. Is the idea that AAL3 would auto install all the below layers?

In my examples, yes... the AAL3 depends on AAL2 and the plugin manages knows how to resolve dependencies. Again, I only used AAL1, AAL2, etc, for sorting reasons.

Originally Posted by jusjoken

I like the concept. It basically can be utilized Out of the Box as you can write a plugin right now that just lists dependencies and will then cause SageTV to install those dependencies as well as their dependencies and so on just by installing this new Layer plugin.

With a few creative developers doing a small portion this could be taken a step further....

• update the core with a new plugin type called "Layer" or "Package"
• update the core STV file to support this new type as a new tab in the Plugin Manager so these are all shown together and not dependent on naming
• update the core STV so the install wizard lists these new "Layers" or "Packages" as an option to install at the end of the wizard.

It may also not be too big a stretch to provide a function in the plugin manager to "Save" your current installed plugin list as a new local "Layer" or "Package" and put it in a file called "SageTVPluginsMyPlugins.xml" and then update the core to recognize this file similar to the "SageTVPluginsDev.xml" file which would then list this "MyPlugins" in the plugin manager for easy install of your complete list of plugins. You could copy this file elsewhere for future installs too.

k

I agree... have a "Layer" type would be ideal to separate them out. That would probably be a small change to the core. My original thought was to do something that didn't really require any core changes (except for stv), but your idea is better (just more work)

Originally Posted by tmiranda

I love the idea. I'd add the Schedules Direct plugin to the base as a PVR without guide data is not very useful.

If nobody else steps up to "own" the SD plugin I'll consider taking on that role.

Maybe the EPG configuration could be a separate part of the "configuration wizzard"? We could ask if they want to use SD (maybe only if they haven't configured an API key), and if so, then install the SD plugin.. This could be before asking the user what layer they want to install.

[Tiki]

Since these "layer" packages consist of plugins written by different authors (who may not use or test with all the other plugins), how do you ensure compatibility with revision changes?

For example, maybe the YouTube plugin was written by an author who only uses and tests with the default Sage7 UI, but it happens to work OK with Gemstone too. So, some other person comes along and creates this "layer" package that includes both the YouTube plugin and Gemstone.

But, then later, imagine that the YouTube plugin gets updated in a way that breaks compatibility with Gemstone.

So, how do you make sure that the "layer" package uses the latest versions of all the underlying plugins, but only if they are compatible?

[KarylFStein]

Originally Posted by Fuzzy

I think there would be an issue with auto-installing the SD plugin at this time. I think it ends up disabling the built-in EPG. That, and we really need to make a UI MOD plugin for it to move the configuration INTO the UI instead of dependent on the web UI.

I'm wondering if it makes sense to look at moving more (all?) of the configuration things to the Web UI. Some things you can only configure in the Web UI, others only in the Sage UI, and some a mixture. It would be kind of nice if there was one configuration location for things and you wouldn't have to worry about possibly adding menu items for it e.g. a Gemstone user adding a new plugin that has a menu item under "Settings".

[nyplayer]

If you go to the layer package will that mean that I have to install every plugin that is in the package even those I do not use? I lke to keep my SageTV install as light a possible.

AAL01 - Base Layer
- sagex/sagex-services
- SageTV Web UI
- SageTV Mobile UI
- Comksip with Comskip UI
- youtube plugin
- upnp plugin


For example I do not use these.... As most android devices have Youtube which is much better.

- youtube plugin
- upnp plugin

[jamesdisco]

Originally Posted by stuckless

Maybe the EPG configuration could be a separate part of the "configuration wizzard"? We could ask if they want to use SD (maybe only if they haven't configured an API key), and if so, then install the SD plugin.. This could be before asking the user what layer they want to install.

Definitely need the SD plugin for us international users, i still can't recommend anyone in the UK to use sage as its way too complex getting UK guide data into sage. If all they had to do was sign up to SD then it becomes much easier to access for the non-techie. You'd probably also want to integrate this plugin too for satellite users. It would stop channels from suddenly stopping working with the dreaded 'No Signal'

[Fuzzy]

Originally Posted by KarylFStein

I'm wondering if it makes sense to look at moving more (all?) of the configuration things to the Web UI. Some things you can only configure in the Web UI, others only in the Sage UI, and some a mixture. It would be kind of nice if there was one configuration location for things and you wouldn't have to worry about possibly adding menu items for it e.g. a Gemstone user adding a new plugin that has a menu item under "Settings".

I can't think of anything BUT the schedules direct that you need to configure in the Web UI. Really, the only reason the SD plugin is done there is because Slugger didn't do STV development. It shouldn't be hard to add a configuration screen for the SDEPG plugin to the UI - just someone needs to do so.

More importantly, Sage needs to be able to have the SDEPG installed and be able to choose between them in the UI. Again, shouldn't be difficult, just the UI doesn't currently support it.

[Fuzzy]

Originally Posted by stuckless

In my examples, yes... the AAL3 depends on AAL2 and the plugin manages knows how to resolve dependencies. Again, I only used AAL1, AAL2, etc, for sorting reasons.



I agree... have a "Layer" type would be ideal to separate them out. That would probably be a small change to the core. My original thought was to do something that didn't really require any core changes (except for stv), but your idea is better (just more work)



Maybe the EPG configuration could be a separate part of the "configuration wizzard"? We could ask if they want to use SD (maybe only if they haven't configured an API key), and if so, then install the SD plugin.. This could be before asking the user what layer they want to install.

Even if you have a key, there are reasons to use SD. Many Non-US/Canada markets, for instance, are supported in the SDEPG, but not in the Core service. I really think that since the SDEPG is only going to be more and more critical, that it needs to become part of the core, and be a selectable option in the wizard - like TVTV was before - and not an added on plugin. It may not actually be that difficult to do - depends on how much 'selection' logic is in the core already.

[KarylFStein]

Originally Posted by Fuzzy

I can't think of anything BUT the schedules direct that you need to configure in the Web UI. Really, the only reason the SD plugin is done there is because Slugger didn't do STV development. It shouldn't be hard to add a configuration screen for the SDEPG plugin to the UI - just someone needs to do so.

More importantly, Sage needs to be able to have the SDEPG installed and be able to choose between them in the UI. Again, shouldn't be difficult, just the UI doesn't currently support it.

Out of the ones I use there are BMT, SageAlert and SJQ, (although someone needs to update the SJQ web interface to accept SageTV > 7.x). So, yeah, Slugger heavy. And I think OpenDCT is moving to web UI configuration.

[HelenWeathers]

I personally feel like the SD EPG shoule be part of the core package and the Sage EPG should be a plugin.

The Sage EPG will only be used by some of us who have license keys and those who do have keys are mostly familiar with plugin installs and properties file edits when needed.

[Fuzzy]

Originally Posted by HelenWeathers

I personally feel like the SD EPG shoule be part of the core package and the Sage EPG should be a plugin.

The Sage EPG will only be used by some of us who have license keys and those who do have keys are mostly familiar with plugin installs and properties file edits when needed.

There's no reason for them not to BOTH be in there - and honestly, it would be far more difficult to pull the core EPG out than it would be to add the SDEPG in with it.

[nyplayer]

Originally Posted by Fuzzy

There's no reason for them not to BOTH be in there - and honestly, it would be far more difficult to pull the core EPG out than it would be to add the SDEPG in with it.

Really the SDEPG is the only plugin needed for New Users anything else should be optional. I always put on my "Sagetv for Dummies" hat when dealing with new users and pretend I know nothing about SageTV. The less decisions a user has to make on initial install the better.

[Skirge01]

Originally Posted by nyplayer

Really the SDEPG is the only plugin needed for New Users anything else should be optional.

While I agree with this, it's a matter of ROI. What does the--apparently somewhat involved--process of pulling out the standard EPG get the project at this point in time? New users? New developers? Easier installation? IMO, the few developers we have don't need to be focusing on things like this. Somewhere down the line, when someone has the free time, maybe doing that will be an effective use of their skills, but not at this early stage of development.

[nyplayer]

Originally Posted by Skirge01

While I agree with this, it's a matter of ROI. What does the--apparently somewhat involved--process of pulling out the standard EPG get the project at this point in time? New users? New developers? Easier installation? IMO, the few developers we have don't need to be focusing on things like this. Somewhere down the line, when someone has the free time, maybe doing that will be an effective use of their skills, but not at this early stage of development.

I guess you misunderstood me I am not talking abut ripping out the EPG. I am talking that SDEPG should be the first plugin that should be concentrated on as all others are optional.

[Skirge01]

Originally Posted by nyplayer

I guess you misunderstood me I am not talking abut ripping out the EPG. I am talking that SDEPG should be the first plugin that should be concentrated on as all others are optional.

Ahh! Gotcha. My mistake. In that case, I agree.