[News] Future of MP Extensions - Design Concept (1 Viewer)

[chefkoch]

The following suggestion / hint is more development related (than user / GUI):

Last weeks I am working on removing the binaries from the MP2 repository using NuGet to automatically download all references and dependencies that are needed to build and run MP2.
While working with NuGet I noticed it is very powerful and well structured.
It mainly consists of the following parts:

• NuGet.Core
• NuGet.exe - CommandLineClient
• NuGet Gallery - Website for hosting and browsing packages (myget gallery example)
• NuGet Package Explorer - GUI for creating, modifying, inspecting and publshing packages
• VisualStudio plugin - a GUI for browsing and installing plugins within VS

The core does not have any dependencies to the other components, but is being reused by them.

Why am I posting this here?
Well, NuGet is open source and managing packages / extensions is exactly the same task that MPEM has to do.
For example specifying dependencies, version ranges, using the semantic version scheme, constraints, all these things are concepts implemented in NuGet and should be ideally available within the MPEM architecture.

Maybe other things can be reused as well. Of course all these things need modifications, but the architecture itself does not need to be reinvented.
As an example even JetBrains is going to use it for managing ReSharper extensions: http://blogs.jetbrains.com/dotnet/2013/04/new-features-in-the-latest-resharper-8-ea/

I can not say how something should be implemented since I am not working on this part, but I wanted to inform you about this and that it might be worth at least to take a look at it.
I am also not sure if this is the right thread. If there is a more appropriate one feel free to move the post or link anywhere if it should not get lost.

 

[tourettes]

The following suggestion / hint is more development related (than user / GUI):

Last weeks I am working on removing the binaries from the MP2 repository using NuGet to automatically download all references and dependencies that are needed to build and run MP2.
While working with NuGet I noticed it is very powerful and well structured.
It mainly consists of the following parts:

• NuGet.Core
• NuGet.exe - CommandLineClient
• NuGet Gallery - Website for hosting and browsing packages (myget gallery example)
• NuGet Package Explorer - GUI for creating, modifying, inspecting and publshing packages
• VisualStudio plugin - a GUI for browsing and installing plugins within VS

The core does not have any dependencies to the other components, but is being reused by them.

Why am I posting this here?
Well, NuGet is open source and managing packages / extensions is exactly the same task that MPEM has to do.
For example specifying dependencies, version ranges, using the semantic version scheme, constraints, all these things are concepts implemented in NuGet and should be ideally available within the MPEM architecture.

Maybe other things can be reused as well. Of course all these things need modifications, but the architecture itself does not need to be reinvented.
As an example even JetBrains is going to use it for managing ReSharper extensions: http://blogs.jetbrains.com/dotnet/2013/04/new-features-in-the-latest-resharper-8-ea/

I can not say how something should be implemented since I am not working on this part, but I wanted to inform you about this and that it might be worth at least to take a look at it.
I am also not sure if this is the right thread. If there is a more appropriate one feel free to move the post or link anywhere if it should not get lost.

This is good info - and it will affect MP2 as well since MPEM should be used for both MP1 and MP2, there is even less need to reinvent the wheel inside the team.

 

[chefkoch]

This is good info - and it will affect MP2 as well since MPEM should be used for both MP1 and MP2, there is even less need to reinvent the wheel inside the team.

That would be great, but requires splitting defintiions from the actual implementations in some parts, just a small example:

• The definition in an xml to collect files when building the package and extract them to a specified directory when installing the package is a core task no matter if is an extension for MP1 or MP2, but
• there might be "special folder" where something is being extracted in MP1, i.e. %Plugins%\windows ,
• but this kind of specification is not relevant for MP2 and thus should not be part of core. Maybe it there need to be core extensions for MP1 and MP2 specifications, so that even these things do not need to be implemented / defined multiple times in the GUI plugin, ExtensionManager application or the ExtensionInstallerService.

(sorry for choosing the wrong wording if there are already defined terms the components)

Nevertheless, I appreciate every work that is being done on the MPEM area very much.


What I love about the NuGet gallery:

• You can store unlimited number of versions so all are still available and because of dependencies from other packages, which can refer to specific versions it is not allowed to simply remove a version or a plugin. This prevents broken dependency chains. To hide, i.e. a buggy release or so it is possible to unlist it, so it is not "visible" anymore.
• You specify the metadata and information about your package once in the .nuspec file. Once you create the nupkg package including the nuspec and the files, it is being uploaded to the website and the data is read from the package. No need to re-enter the all the plugin information again, which would result in inconsistent information / descriptions etc between packages that are browsed online, within GUI and those that are already installed.

Another note: If the current used online repository is does not fulfill our needs or it is hard to extend it, we should consider an alternative. Maybe the NuGet gallery could be a base. It is written in Asp.Net, iirc and that might also allow other .NET developers to help out with fixes and/extensions if these might be required in future.

 

[sa_ddam213]

The following suggestion / hint is more development related (than user / GUI):

Last weeks I am working on removing the binaries from the MP2 repository using NuGet to automatically download all references and dependencies that are needed to build and run MP2.
While working with NuGet I noticed it is very powerful and well structured.
It mainly consists of the following parts:

• NuGet.Core
• NuGet.exe - CommandLineClient
• NuGet Gallery - Website for hosting and browsing packages (myget gallery example)
• NuGet Package Explorer - GUI for creating, modifying, inspecting and publshing packages
• VisualStudio plugin - a GUI for browsing and installing plugins within VS

The core does not have any dependencies to the other components, but is being reused by them.

Why am I posting this here?
Well, NuGet is open source and managing packages / extensions is exactly the same task that MPEM has to do.
For example specifying dependencies, version ranges, using the semantic version scheme, constraints, all these things are concepts implemented in NuGet and should be ideally available within the MPEM architecture.

Maybe other things can be reused as well. Of course all these things need modifications, but the architecture itself does not need to be reinvented.
As an example even JetBrains is going to use it for managing ReSharper extensions: http://blogs.jetbrains.com/dotnet/2013/04/new-features-in-the-latest-resharper-8-ea/

I can not say how something should be implemented since I am not working on this part, but I wanted to inform you about this and that it might be worth at least to take a look at it.
I am also not sure if this is the right thread. If there is a more appropriate one feel free to move the post or link anywhere if it should not get lost.

Just when I thought I was done with the base design for the Plugin Updater Service you drop this bombshell, ROFL.

So I started researching this last night and I think using NuGet for extensions would be awesome, i aslo came across project Shimmer .
Its basically an Auto-Update service using Nuget packages , Its pretty much the same as Click-Once but without all the restrictions.

Any thoughts on adapting this project for use in MPEM??

 

[infinite.loop]

Any thoughts on adapting this project for use in MPEM??

We already use nuget in the team since a few weeks to pull external binaries and nolonger store them in our repo.
So if you think that MPEM would benefit from using nuget too, then I am all for that!

 

[sa_ddam213]

Any thoughts on adapting this project for use in MPEM??

We already use nuget in the team since a few weeks to pull external binaries and nolonger store them in our repo.
So if you think that MPEM would benefit from using nuget too, then I am all for that!

My first concern is backward compatability with the current MPE1 installers (this is what my current implementation uses), using a NuGet solution I am no sure how easy it would be to do.

Are we expecting all plugin/skin developers to update to a new installer system, or do we NEED backward compatability in the Plugin Installer Service?

I guess I could make the service a bit more abstract so we can handle differnt install packages (NuGet, MPE1, EXE) but perhaps it would be better to create a new standard for installers, especially in MP2 is planning on using NuGet for plugins.

Would love to hear some feedback before I start on the refactor of the Plugin Service Installer (or maybe just MPUpdater since it can upadte MP itself )

 

[chefkoch]

I am very sorry that I did not posted this earlier, but I also got in touch with NuGet the first time by the end of March / beginning of April. Additionally I was not aware that there is serious development on this area, because I did not follow this thread. So thanks a lot for all your efforts.

My first concern is backward compatability with the current MPE1 installers (this is what my current implementation uses), using a NuGet solution I am no sure how easy it would be to do.

Are we expecting all plugin/skin developers to update to a new installer system, or do we NEED backward compatability in the Plugin Installer Service?

I guess I could make the service a bit more abstract so we can handle differnt install packages (NuGet, MPE1, EXE) but perhaps it would be better to create a new standard for installers, especially in MP2 is planning on using NuGet for plugins.

Would love to hear some feedback before I start on the refactor of the Plugin Service Installer (or maybe just MPUpdater since it can upadte MP itself )

Having abstract implementations and appropriate interfaces is always good, but if it only bloats or makes it too complex we should avoid it.

In this case in my opinion executables like the LAVF installer will could be wrapped somehow into the new package format to wrap the metadata around the installer. Even if it would be allowed to specify external URLs to prevent saving a duplicated executable again for each new version on our own server, the metadata is specified/provided by a NuGet pacakge. So I do not see a plain executable on it's own as a format/package that the installer should be able to handle.

Regarding the MPE1, I expect that MPEM won't be available for older MP versions like 1.1 or 1.2 etc... so existing plugin version compatible with those are not needed to be installed via MPEM. For new version it is possible that we already break the compatibility with existing plugins by bumping the version because of other code related changes. If it is easy to create new MPEM packages (similar to the NuGet packages) the plugin devs will prefer it over the MPE1. For not maintained or older plugins the team can help out to create packages.

So in the end if you would like to keep handling existing MPE1 packages out, feel free to do so, imo.

The new format itself once specified, might also be need some extensions in future. There we need to ensure older packages are also handled by newer MPEM core installations.

 

[infinite.loop]

Any thoughts on adapting this project for use in MPEM??

We already use nuget in the team since a few weeks to pull external binaries and nolonger store them in our repo.
So if you think that MPEM would benefit from using nuget too, then I am all for that!

My first concern is backward compatability with the current MPE1 installers (this is what my current implementation uses), using a NuGet solution I am no sure how easy it would be to do.

Are we expecting all plugin/skin developers to update to a new installer system, or do we NEED backward compatability in the Plugin Installer Service?

I guess I could make the service a bit more abstract so we can handle differnt install packages (NuGet, MPE1, EXE) but perhaps it would be better to create a new standard for installers, especially in MP2 is planning on using NuGet for plugins.

Would love to hear some feedback before I start on the refactor of the Plugin Service Installer (or maybe just MPUpdater since it can upadte MP itself )

Compatibility can go out of the door if you ask me. Better to have a clean cut and start doing things better for the future than trying to stay compatible and end up with a solution that is not ideal.

As long as the creation of the packages is simple (currently it isn't that easy), this is not an issue.

 

[sa_ddam213]

We already use nuget in the team since a few weeks to pull external binaries and nolonger store them in our repo.
So if you think that MPEM would benefit from using nuget too, then I am all for that!

My first concern is backward compatability with the current MPE1 installers (this is what my current implementation uses), using a NuGet solution I am no sure how easy it would be to do.

Are we expecting all plugin/skin developers to update to a new installer system, or do we NEED backward compatability in the Plugin Installer Service?

I guess I could make the service a bit more abstract so we can handle differnt install packages (NuGet, MPE1, EXE) but perhaps it would be better to create a new standard for installers, especially in MP2 is planning on using NuGet for plugins.

Would love to hear some feedback before I start on the refactor of the Plugin Service Installer (or maybe just MPUpdater since it can upadte MP itself )

Compatibility can go out of the door if you ask me. Better to have a clean cut and start doing things better for the future than trying to stay compatible and end up with a solution that is not ideal.

As long as the creation of the packages is simple (currently it isn't that easy), this is not an issue.

Sounds good to me

Starting a new installer sytem for MPEM will make everything a lot easier, I can add all the package creation into MPEM UI along with deployment.

One thing that still bothers me is plugins that require external config apps, this has aways been a pain for me with my personal MP installs because my HTPC is very difficult to connect to a mouse/keyboard due to its location.

I have a very wild idea to fix this issue because I'm sure it affects more than just me, if we are going to create a wizard to create the installers, why not add a wizard to create a GUIWindow so all config can be handled directy in MP or from the MPEM UI. I know that sound like a fair bit of work but I have just finished the SkinCreator for MPDisplay and the new MPDisplay skin xml format is VERY close to MediaPortals skin xml format so with a few tweaks it could easily create MP windows with simple drag-drop. (attached Editor below if you want to have a look, It wont need to be as extensive for MPEM,LOL)

Or we could simply create a PluginConfig interface that can be consumed by the devs to create configx that can be accesed by MPEM. Really not sure about this part.

I am going to try get some NuGet testing done this week to make sure its going to play nice with UAC, because if this ends up being an issue we may have to re-think a few things.

I will keep everyone updated on this

 

[infinite.loop]

MPEM is a big project. To ensure that the discussions can be done in a clean way and don't end up in 10+ pages long threads with a lot of different things discussed inside, I have now created a MPEM forum section.

https://forum.team-mediaportal.com/forums/general.656/