Discussion: Plugin architecture changes

[Fuzzy]

Originally Posted by stuckless

I'm pretty sure the "inherit" model solves this entirely, since sagetv does all the rest. ie, it already can read multiple plugin sources, and it figures out the "latest" as it does it. (ie, SageTVPlugins.xml and SageTVPluginsDev.xml). So, making a small change to sagetv to load multiple repositories would solve all those issues of min/max, etc..

Not entirely, as currently, it simply keeps the version with the highest version tag from either XML. It also uses the ID as the key when bringing it in, so it likely won't work right unless the key is changed to a composite property of ID and version. Then it also needs to not simply select the highest version, but select the highest version that is compatible on the system. Not all impossible, just not as simple as loading in more than one XML at a time.

[stuckless]

Originally Posted by Fuzzy

Not entirely, as currently, it simply keeps the version with the highest version tag from either XML. It also uses the ID as the key when bringing it in, so it likely won't work right unless the key is changed to a composite property of ID and version. Then it also needs to not simply select the highest version, but select the highest version that is compatible on the system. Not all impossible, just not as simple as loading in more than one XML at a time.

Maybe I'm missing something here... but if there is a S9 Repo that inherits from S7 Repo, then the S9 repo is compatible with Sage9 and S7 repo is compatible with S7?? Again, not talking about the JVM requirements, just the segregated SageTV plugins that are compatible by sagetv major version.

People on Sage7 wil never see S9 plugins or S9 plugin updates, but S9 users will see S7 plugins.

[Narflex]

I'm actually confused now about whether SageTV properly handles multiple versions of the same plugin....

From looking at CorePluginManager.java, it definitely can process multiple plugins with the same ID in the repo and maintains 2 maps...one that has ALL the versions of a plugin, and then another one which is just the latest version. There's even a SageTV API call for getting all the plugin objects (i.e. all versions) for a specific plugin ID. When you install a plugin; it will find the proper dependency version as well from the manifest and choose to install that. However...there's no way outside of using the Devs + SageTV manifest files to get SageTV to see multiple versions of the same plugin in the repo currently.

On the server end of things...it definitely does not deal with multiple versions of the same plugin. When you upgrade a plugin...it kills the old manifest, period. It also prevents removing plugins that other plugins are dependent upon.

So it looks like I did support for this on the client side of things...but then abandoned it when the plugin verifier server was written.

I *think* my line of thinking was that if you're upgrading a plugin (which is a dependency of other plugins), then when you do that you should be sure it's backwards compatible. And in the event that it's not, then you should just give it a new plugin ID and whatever other plugins are dependent upon that newer version, they should use that new ID. This of course breaks down based on another rule (which i don't believe is enforced anywhere) that two different plugins should never reference the same JAR file (or different variants of it, like 2 different Lucene versions).

There is also a custom ClassLoader used in the plugin system. However, the only purpose of it is to be able to dynamically add new JAR files to the classpath at runtime so you don't need to restart SageTV if the plugin just adds a JAR file and you're loading stuff from that.

I'm not really sure what to do about this whole plugin thing right now...but I really don't want to fracture the plugin system at the V9 boundary and make it totally separate from what existed before then. There's LOTS of great plugins in the current repo, and starting over from scratch doesn't seem like a great idea.

Creating a secondary (or nth) repository...where it downloads from all and merges them together (since it seems to already handle that) would likely be fine.

[Monedeath]

Originally Posted by stuckless

Hosting won't be much of an issue, but the "validating system" part might imply a server running somewhere, and I'm not sure who wants to foot the bill for that. Technically anybody, including myself, that has a server in their house, could do the "validation" part of this, and then git commit the new/updated plugin xml if it passes.

As for hosting, I did create an OpenSageTV organization on GitHub a few days ago.
https://github.com/OpenSageTV
Organizations are similar to users, except they can have multiple admins. Users can have specific roles, etc.

Server hosting costs online these days isn't too outrageous.

linode.com for example can have you setup with a virtual server w/1GB Ram, 1 CPU Core, 24GB storage, 2TB/month transfer, 40Gbit in/125Mbit out for $10 per month.

There are other provisioning options out there as well, now granted depending on other factors and if all goes well, needs in several respects may grow over time(and the associated costs). But virtual hosting these days is a far cry from 10+ years ago, and less outrageously expensive.

[Fuzzy]

Originally Posted by Monedeath

Server hosting costs online these days isn't too outrageous.

linode.com for example can have you setup with a virtual server w/1GB Ram, 1 CPU Core, 24GB storage, 2TB/month transfer, 40Gbit in/125Mbit out for $10 per month.

There are other provisioning options out there as well, now granted depending on other factors and if all goes well, needs in several respects may grow over time(and the associated costs). But virtual hosting these days is a far cry from 10+ years ago, and less outrageously expensive.

we could always validate via an offline tool and build a mini-torrent system into sage that could be used for all the plugins... ;-)