Philosophy for core vs plugins

[Tiki]

Originally Posted by Damstas

Card server and Phoenix card reader support or card support in general (!!!!)

What is a Phoenix card? Why would we want it for Sage?

From a quick web search, it appears to be some sort of smart card... is this used for decrypting premium content in some parts of the world (sort of like cable card in the US)?

[Damstas]

Originally Posted by Tiki

What is a Phoenix card? Why would we want it for Sage?

From a quick web search, it appears to be some sort of smart card... is this used for decrypting premium content in some parts of the world (sort of like cable card in the US)?

In short, yes. It's supported in NextPVR and TVHeadend etc. Multidec seems to be the correct term: http://www.nextpvr.com/nwiki/pmwiki....DialogMultidec

[stanger89]

Originally Posted by Damstas

Could these features be added to the core:

In addition to Schedules Direct, TheTVDB and TMDB search. The engine would need to be programmed to bypass the Nordic EPG age restriction, which are at the end of the show name: (7), (12), (16), (18), (R), (S) and (T). This feature is already in NextPVR.
Movies have "Elokuva:" in front of them, atleast in Finland.

Most of that (other than Schedules Direct) seems like the perfect thing for a plugin, actually it already is, BMT.

[skiingwiz]

Originally Posted by stanger89

The thing to remember though, is there's two issues here, and they are not the same:

1) The SageTV architecture, what components/features should be "plugins" and what parts should be built in.
2) The "SageTV" package, what should be included and automatically installed/configured when you run the installer.

Agree completely. This gets everyone (mostly) what they want. The core stays small, focused, and stable. The common functionality is installed by default (as plugins).

This also allows those common plugins to be updated without needing to upgrade the entire install, which could prevent downtime. [which was mentioned before as well]

[wayner]

Originally Posted by skiingwiz

This also allows those common plugins to be updated without needing to upgrade the entire install, which could prevent downtime. [which was mentioned before as well]

But it would be great if the system allowed plugins to be fully upgraded without requiring a restart of the service - if I recall correctly a great deal of plugins require you to restart the service which is an annoyance - just like Windows application upgrades requiring a reboot.

[Fuzzy]

Some of those are simply due to how the plugin is written, and can sometimes be avoided without any changes to sage's architecture.

[stuckless]

Originally Posted by Fuzzy

Some of those are simply due to how the plugin is written, and can sometimes be avoided without any changes to sage's architecture.

I don't think so. Unless a base architecture loads classes into separate classloader from the kernel (ie, Sage in this case), then you cannot "unload" a plugin that has any .class files.

In Java App Servers use a separate ClassLoader to load each web app, and basically when you reload the web app, java will clean up the best it can, and then create a new ClassLoader and reload the class files into that classloader. This process typically results in a small memory leak over time, since Java will never release the loaded Class data (it will release the instance data).

Fundamentally this solution involves using ClassLoaders to load plugins (which is what all major plugins system use, in Java), and I don't think SageTV does this.

[Narflex]

Originally Posted by stuckless

Fundamentally this solution involves using ClassLoaders to load plugins (which is what all major plugins system use, in Java), and I don't think SageTV does this.

I considered doing ClassLoaders for awhile...but then we'd run into potential problems where a plugin class was not fully isolated...so even killing and unloading the plugin wouldn't fully unload its classes and there wasn't a good way to detect that which I was aware of. There's too much interaction between plugins and the core...there's not the kind of isolation you see when running WebApps.

[stuckless]

Originally Posted by Narflex

I considered doing ClassLoaders for awhile...but then we'd run into potential problems where a plugin class was not fully isolated...so even killing and unloading the plugin wouldn't fully unload its classes and there wasn't a good way to detect that which I was aware of. There's too much interaction between plugins and the core...there's not the kind of isolation you see when running WebApps.

I agree, it's a complicated mess, with the only advantage being able to load/unload plugins without restarting. At the very least, if ALL plugins were in a separate loader, you could unload/reload all plugins without restarting the kernel. Java 9 is support to help with this, and osgi already does this, but sadly osgi is overkill for something this simple.

In theory it doesn't really matter how much of the core the plugin uses... since calling shutdown() on the plugin in one classloader should effectively unlink it from core... and then the new classloader would call start() and it will rebind to the core. (in theory, of course )