Warning: This thread targets developers more than users. Keep this in mind when reading and maybe replying.
There have been several concepts for managing plugins and skin or let's say extensions during the last years and again the last months.
While the first trials to implement an extension installer (MPEI) have been done with spending a lot of efforts and are even better than what there was before (nothing or zips, or exe installer, ...), it still has a lot of architectural design issues, which results problems maintaining packages for the plugin authors and even for our admins managing the list of available plugins etc.
Many of the concepts' that have been raised since first implementation of MPEI, mostly focused on the graphical user interface first, then the usability and last but not least "some" versioning and dependency concepts.
There are several major architectural drawbacks imo:
List is incomplete, went to bed before I finished it
In my opinion the priority of things to focus is the other way around. It's more the way MP2 has been built during the last years.
The core
The most important for such a extension management is the it's core, which will be reused in several other components.
The core component knows how to pack (build/compile), install, uninstall, update, reinstall an extension.
It's code that might might be available within a dll and so can be reused or even better a powerful command line application that is being reused by the other components.
The "fancy" components
The following list just gives examples:
Why am I posting this now? here?
Why yet another thread about it?
Why aren't there any requirements or specifications?
Simple answer: I won't be to work on this, because of the lack of spare time (busy with real life) within the next weeks/months, but I know this is a very important component for MP2.
If done correctly it can already improve the plugin installation experience for MP2 a lot. There is not need to have a fancy app for browsing extensions in GUI. It would already be great having
So what it is all about: The NuGet-approach of managing extensions, versions and dependencies.
During the last weeks I worked a lot with NuGet. I removed almost all binaries from the MP2 source code (https://issues.team-mediaportal.com/browse/MP2-292) and integrated them via packages from the official NuGet feed or via our own packages from our own nuget feed.
Maybe this is a great architecture that can be used for managing extensions in MediaPortal 2 as well. I don't know if it is the solution, but I imagine it could be a major part of it. That's why I am writing this post. Spreading the word about it and what others already do with nuget in their own projects / applications.
So if you think this an interesting topic or you know alternative solutions, please share your thoughts.
If you might be interested in working on such a task definitely get in contact with us.
Further information about NuGet:
There is also another project:
We would like to target end users again, so maybe it is possible to reuse many things from the OrchardGallery and merge it into our own custom nugetgallery (both are based on the GalleryServer http://galleryserver.codeplex.com/):
Others who are already (will be) reusing Nuget for their own applications:
Like I already said I really would like to read and work myself deeper into that topic and evaluate the possibilities, but that's won't be possible because real life these days. Nevertheless I will keep an eye on other NuGet developments. forks and projects that are going to use it and will post them here.
Please excuse any mistakes and parts that make no sense. It's almost sunrise here Feel free to edit my post
There have been several concepts for managing plugins and skin or let's say extensions during the last years and again the last months.
While the first trials to implement an extension installer (MPEI) have been done with spending a lot of efforts and are even better than what there was before (nothing or zips, or exe installer, ...), it still has a lot of architectural design issues, which results problems maintaining packages for the plugin authors and even for our admins managing the list of available plugins etc.
Many of the concepts' that have been raised since first implementation of MPEI, mostly focused on the graphical user interface first, then the usability and last but not least "some" versioning and dependency concepts.
There are several major architectural drawbacks imo:
List is incomplete, went to bed before I finished it
- Definition of a package (creating it) is too complicated: There is no need for a GUI to create plugin / extension package if the xml syntax is well documented and extremely powerful.
- The concepts were always focused on MP1's architecture with different kind of extensions' like
- MP1 vs. TVServer
- For MP: Windows, process, .....
- and skin of course
- These kind of plugins do no exist anymore within MP2. Here everything is a plugin no matter if it is code extension (classic plugin) or a skin
- The most "important" within these concepts mostly was the GUI to browse and manage plugins for the end user.
In my opinion the priority of things to focus is the other way around. It's more the way MP2 has been built during the last years.
- First build a powerful, flexible and easy to maintain architecture. This can be ugly from the user pov
- Then later you can build the fancy parts around.
The core
The most important for such a extension management is the it's core, which will be reused in several other components.
The core component knows how to pack (build/compile), install, uninstall, update, reinstall an extension.
It's code that might might be available within a dll and so can be reused or even better a powerful command line application that is being reused by the other components.
The "fancy" components
The following list just gives examples:
- Online Repository: The online repository / gallery also is built around the core. There is no need to enter all the plugin information again, no need to list the dependencies again or manage various download locations for different versions. All these things are managed automatically by the online repository and metadata is read from the uploaded extension packages.
- GUI plugin: A plugin for MP2-Client to browse installed plugins on the current client, the server and any other client within the network, which is attached to the same server.
- Managing you client's and server's extensions from within the browser? Imagine we could have a webinterface for configuring MediaPortal 2 through the browser. Why not also installing and updating plugins from there. For some talk and discussion about this see https://forum.team-mediaportal.com/...ure-mp2-browse-edit-play-medialibrary.119978/
- A separated extension installer application: see https://forum.team-mediaportal.com/forums/general.656/
Why am I posting this now? here?
Why yet another thread about it?
Why aren't there any requirements or specifications?
Simple answer: I won't be to work on this, because of the lack of spare time (busy with real life) within the next weeks/months, but I know this is a very important component for MP2.
If done correctly it can already improve the plugin installation experience for MP2 a lot. There is not need to have a fancy app for browsing extensions in GUI. It would already be great having
- an online repository just as a simple listing of available plugins
- an local application listing installed plugins and showing available updates
So what it is all about: The NuGet-approach of managing extensions, versions and dependencies.
During the last weeks I worked a lot with NuGet. I removed almost all binaries from the MP2 source code (https://issues.team-mediaportal.com/browse/MP2-292) and integrated them via packages from the official NuGet feed or via our own packages from our own nuget feed.
Maybe this is a great architecture that can be used for managing extensions in MediaPortal 2 as well. I don't know if it is the solution, but I imagine it could be a major part of it. That's why I am writing this post. Spreading the word about it and what others already do with nuget in their own projects / applications.
So if you think this an interesting topic or you know alternative solutions, please share your thoughts.
If you might be interested in working on such a task definitely get in contact with us.
Further information about NuGet:
- Homepage: http://nuget.org/
- NuSpec > NuGet package specification: http://docs.nuget.org/docs/reference/nuspec-reference
- nuget versioning: http://docs.nuget.org/docs/reference/versioning
- package conventions: http://docs.nuget.org/docs/creating-packages/package-conventions
- NuGet @ codeplex: http://nuget.codeplex.com/
- NuGet @ github: https://github.com/NuGet (NuGetGallery: https://github.com/NuGet/NuGetGallery )
- NuGet in action / presentations >>> Videos: http://docs.nuget.org/docs/start-here/videos
- Components:
- NuGet.Core > versioning algorithm, dependency management, package metadata, ...
- NuGet.exe > commandline tool for installing, uninstalling, updating, reinstalling, ....
- NuGet.Server > WebComponent for hosting packages and providing a feed that can be reused by "clients" (external installer, GUI plugin, Gallery, ....)
- NuGetGallery (OrchardGallery) > (ASP.net based?) WebSite component presenting available packages nicely in your browser
- NuGetPackageExplorer > Utility for building and uploading packages
There is also another project:
- The Orchard gallery: http://gallery.orchardproject.net/
We would like to target end users again, so maybe it is possible to reuse many things from the OrchardGallery and merge it into our own custom nugetgallery (both are based on the GalleryServer http://galleryserver.codeplex.com/):
NuGet + OrchardGallery + MediaPortal extensions = The ultimate extension experience
Others who are already (will be) reusing Nuget for their own applications:
- JetBrains managing ReSharper plugin using NuGet:
- http://blogs.jetbrains.com/dotnet/2013/04/new-features-in-the-latest-resharper-8-ea/
- http://blogs.jetbrains.com/dotnet/2013/05/resharper-8-eap-nuget-based-extension-manager/
- http://blogs.jetbrains.com/dotnet/2013/05/creating-plugins-for-dotpeek/
- ReSharper gallery: https://resharper-plugins.jetbrains.com/
- ReSharper package specification: http://confluence.jetbrains.com/display/ReSharper/1.9 Packaging (R8)
- ReSharper gallery (NuGetGallery fork): https://github.com/JetBrains/ReSharperGallery
- "Packages for your system" - Chocolatey
- Existing forks of NuGetGallery: https://github.com/NuGet/NuGetGallery/network
- Other resources / blogs that might be useful:
- http://blogs.planetcloud.co.uk/mygreatdiscovery/post/Nuget-the-perfect-plugin-manager.aspx
- http://www.aaron-powell.com/posts/2011-02-20-creating-a-nuget-plugin-engine.html
- http://haacked.com/archive/2011/01/15/building-a-self-updating-site-using-nuget.aspx
- Using NuGet for Application Plug-Ins
- NuGet Versioning Algorithm:
Like I already said I really would like to read and work myself deeper into that topic and evaluate the possibilities, but that's won't be possible because real life these days. Nevertheless I will keep an eye on other NuGet developments. forks and projects that are going to use it and will post them here.
Please excuse any mistakes and parts that make no sense. It's almost sunrise here Feel free to edit my post
Last edited: