MPEM Development Info & Testversion (2 Viewers)

[chefkoch]

The point is: your concept having the MPEM browser and the MPEM UpdaterService are definitely required components. These perfectly fit into a Extensions Management concept, but how do you plan to define dependencies between plugins, additional specific versions or version ranges. This is fundamental for the extension management, and I think here is already a lot of work done by the NuGet.Core.

NuGet packages itself are no executables, these are just zip files having a different file extensions and containing the files that have been defined to be packed into the package of course and the metadata. Using the NuGet core it should be possible to read such metadata applications like the MPEM browser and MPEM Updateservice.
The good thing is the metadata is the same specification inside the nuget package as well as when creating the package or when retrieving the available inforamtion from the nuget gallery (website).

Like I already wrote in the other thread I am very sorry I can not help with working actually on this topic, current, even not on the nuget area, as I am finishing my studies these weeks and still have a lot to do to make it in time, but other than using NuGet for development dependencies I also did not work more with it, yet. So my knowledge about using it in your own application is the same as yours, nevertheless I believe this is the worth to take a look at it even if it takes some time.
I would understand if you don't want to put so much efforts into it when working alone, so it would be great if there are others who could contribute and support you.
I was asked for my opinion and wrote it down, the concerns about Wix and an alternative which comes with a versioning and dependency concept, a package creator, a server component for hosting the packages and a gallery for browsing these online.

It's your decision, you also can go the WiX route and if you prove it's working the team will be happy to have it.

The offer I can make from my side is assisting in any overall questions, do some testing and reviewing concepts and code, but I won't be able to take over any development tasks this year anymore.

 

[Dadeo]

A few of these things might not fit our needs perfectly i.e. the NuGetGallery which package pages "do not look good" (Dadeo)

HA HA! I did revise that opinion after seeing the http://gallery.orchardproject.net/ - however Orchard is a CMS i.e. competitor to Joomla and I don't know if you are proposing we switch our whole website to Orchard, or how we integrate the two, or who has volunteered to do all that? At the very least we are talking about finding someone interested in learning a new CMS and customizing it to suit our needs (and we have rarely succeed at that in the past -we just assume high is willing to do everything). Gallery Server Project is no longer maintained btw.

I do like the approach and benefits of NuGet - at least what I have read and understood so far. I just think we need to at least consider the full solution and the Online Repository is a huge component of that. I think there are possible solutions we need to explore. Ofc we need the best/easy solution for developers, but we also need to ensure that users will be attracted and can easily find and learn about extensions that may interest them and are compatible with their current MP release. That is one of the big things I love about the design concept of MPEM!

 

[chefkoch]

I don't know if you are proposing we switch our whole website to Orchard

No, definitely not!

or how we integrate the two

The same way the forum is integrated, which is also not Joomla
Or the issue tracker.

or who has volunteered to do all that?

Who has volunteered to work on the existing repository? Maybe I am wrong and it is meets the needs for the most of the plugins/skin devs. Great then there is nothing needed to be done.

IMO it has two huge disadvantages:

• entering the same metadata for a plugin multiple times: 1. when creating the packages in the package creator 2. when uploading the package within the repository
• There is no version management. The links change when uploading a new package and / or old versions won't be available anymore. Without the possibility to keep even older version it will not be possible to run a fine grained extension management with extensive dependency definitions to other plugins.

At the very least we are talking about finding someone interested in learning a new CMS and customizing it to suit our needs (and we have rarely succeed at that in the past -we just assume high is willing to do everything).

I don't assure that high sets up a new CMS: It's only about two components NuGet.Server (#1, #2) and NuGetGallery - And even those should definitely not be customized by high since this is part of extension management. The NuGetGallery is written in ASP.net so once you learned a few things it should be easy to make some small modifications for a .NET/c# developer. Of course this does not "look" good, yet, but that's where code, components or parts from the orchard gallery can be used. I might let it sound easy , yeah, but I am also aware that it is not easy, nevertheless I think it is worth it.

Gallery Server Project is no longer maintained btw.

This was only the base for the Orchard gallery and the NuGetGallery. Both are maintain pretty well.

That is one of the big things I love about the design concept o MPEM!

MPEM is not wrong, it's pretty good and perfect, but as far as I know there was no work done, yet "under the hood". Feel free to correct me if I am wrong. There are no connections to the online repo, yet, no versioning algorithm, no dependency specification. Such might be able to implement easily using nuget.core (even without the nuget.server or nuget.gallery)


EDIT: Yet another idea, I got a few minutes ago: Why not continuing the work on MPEM and the server etc. like it was planned without any nuget or wix things? Just introducing a replacement for the current MPInstaller and having the possibility to install these without the uac prompt should be a huge improvement already that is worth doing it, isn't it?


But it's correct all possibilities needs to be evaluated pretty well.

Since I can't help with this, I will also stop promoting NuGet here in this thread, because I know that it is easy, but just unfair to say "hey why not doing it this way or that way" without actually helping.

So it's up to the people who are actually spending their time on this task.

 

[Dadeo]

I'm not sure if this is OT or not - I am going by:

The repo stuff is really not my area, I have very little web skill except simple MVC junk, but there will need to be changes and I'm really going to need input

But if a separate thread for Repo issues/integration would work better for you sa_ddam213 I can move these posts.

The same way the forum is integrated, which is also not Joomla

Or Wiki? Yep, but it IS a nightmare!

Who has volunteered to work on the existing repository?

Um Me? I guess the team is unaware of how many hours high and I spend integrating and testing the new features for each update. There are a few others who help (esp catavolt with translations) but no devs

IMO it has two huge disadvantages: entering the same metadata for a plugin multiple times: 1. when creating the packages in the package creator 2. when uploading the package within the repository There is no version management. The links change when uploading a new package and / or old versions won't be available anymore. Without the possibility to keep even older version it will not be possible to run a fine grained extension management with extensive dependency definitions to other plugins.

Agreed, at present - however our repo does support updating from external sources, we just never used/tested it yet since MPEI did not support it. IIUC correctly it is sa_ddam213's plan to auto publish/update Repo listing, and I agree that is an important criteria.
Version management is the big issue imo. However, most sites that use our Repo software host the downloads externally, which many of our extensions also do currently. Since Google Code will not support creating new downloads starting January 15th, 2014 I am sure many extensions will be looking for an alternative. So one option is to use a combo of our current repo and NuGet - perhaps even linking to a very simple NuGet gallery for downloads (thus no 'fancy' stuff required there) Ofc there are pros and cons to both methods, but I don't feel I know enough yet to evaluate that!

it should be easy to make some small modifications for a .NET/c# developer.

LOL you already know that is the crux of my concern. It was a disaster every time we tried it in the past. And I would love to forget the past and have hope that can be done, but first I would like to find the person interested who is willing to actually learn the user requirements for an online repo

 

[Dadeo]

The good news is I finally managed to get .Net 4.5 downloaded installed (1.5+ hrs with my internet ) and could try the test version. I really like it a lot

I'm not sure exactly what all should be working yet - Categories and Filters did not work for me, nor the Most Downloaded/New/Updated etc - I assume that requires the integration with repo?

Some minor issues I noticed:

1. ON the Full Details view - the text 'External Changelog' in the right panel cuts off a bit
2. IS MPEM DPI aware? I don't use it because so many apps don't support it, but I do increase the font sizes in Advanced Appearance Settings in Windows and that cuts off some more text in some cases (but not all ) - see attached screenshot
3. Small screenshot res is really bad imo - Where are you grabbing those from? Repo screenshots and resizing down? If so, the thumbnail sizes in Repo are fine so @high can probably help you access those.
4. It took me a few secs to realize I had to press the back arrow to go from Details view back to Overview - I keep clicking the full bar (behind the text) DUH!
   So maybe make the Back arrow button blue or make the whole button 'clickable'
5. Personally I found the small font (e.g. type, category, latest release plus labels and desc text in Details View) really hard to read - but I can understand it's not easy to fit everything on the screen.
6. I found the scrolling a bit confusing because I could only scroll horizontally in the Overview window, and only vertically in the Details view. Personally I prefer vertical scrolling, but mainly I prefer consistency.

And some suggestions:

1. Double click to open Full Details view?
2. Double click the displayed category or extension type to see related extensions (I know you can just use the menu, but just an idea )
3. Esc to go back to Overview from Details?
4. Add MP version installed to 'My System' (which I really liked btw)
5. Is there a place to display a package logo? Or is that what you mean to display as the image for each listing? If so most package icons are square - and it should be the same icon/logo that displays in Plugin Config though not all extensions have one - they don't even all provide package logos for MPEI . I want to add a new image field for that in our Repo (just so you know we can publish that to repo to in future).

 

[Dadeo]

Since I can't help with this, I will also stop promoting NuGet here in this thread, because I know that it is easy, but just unfair to say "hey why not doing it this way or that way" without actually helping.

Well I appreciate your promotion and innovative, creative ideas, and thinking out of the box!! And I trust your experience and evaluation about the potential development benefits. I just want to advocate caution, and more research and testing, including the final solution (online presentation) before jumping the gun.

 

[sa_ddam213]

The good news is I finally managed to get .Net 4.5 downloaded installed (1.5+ hrs with my internet ) and could try the test version. I really like it a lot

I'm not sure exactly what all should be working yet - Categories and Filters did not work for me, nor the Most Downloaded/New/Updated etc - I assume that requires the integration with repo?

Some minor issues I noticed:

1. ON the Full Details view - the text 'External Changelog' in the right panel cuts off a bit
2. IS MPEM DPI aware? I don't use it because so many apps don't support it, but I do increase the font sizes in Advanced Appearance Settings in Windows and that cuts off some more text in some cases (but not all ) - see attached screenshot
3. Small screenshot res is really bad imo - Where are you grabbing those from? Repo screenshots and resizing down? If so, the thumbnail sizes in Repo are fine so @high can probably help you access those.
4. It took me a few secs to realize I had to press the back arrow to go from Details view back to Overview - I keep clicking the full bar (behind the text) DUH!
   So maybe make the Back arrow button blue or make the whole button 'clickable'
5. Personally I found the small font (e.g. type, category, latest release plus labels and desc text in Details View) really hard to read - but I can understand it's not easy to fit everything on the screen.
6. I found the scrolling a bit confusing because I could only scroll horizontally in the Overview window, and only vertically in the Details view. Personally I prefer vertical scrolling, but mainly I prefer consistency.

And some suggestions:

1. Double click to open Full Details view?
2. Double click the displayed category or extension type to see related extensions (I know you can just use the menu, but just an idea )
3. Esc to go back to Overview from Details?
4. Add MP version installed to 'My System' (which I really liked btw)
5. Is there a place to display a package logo? Or is that what you mean to display as the image for each listing? If so most package icons are square - and it should be the same icon/logo that displays in Plugin Config though not all extensions have one - they don't even all provide package logos for MPEI . I want to add a new image field for that in our Repo (just so you know we can publish that to repo to in future).

The UI is still very mockup and based directly of the concept images, Some of the layout I have issues with myself(especially that back button), just had a look and DPI Aware was turned off, so that is probably the reason for the poor text quality/artifacts.

All the data in the concept UI can be found in the Xml's in the Data folder, at the moment it just fetches images from links and cache's them locally to save bandwidth, Fell free to edit the Data Xml's add some more plugins for the other category's and the filters will work correctly, there is just no plugins assigenb to those categories.

All the suggestions sound good and I will integrate them.
Package logos is something I forgot to ask about, it would be nice if the plugin designer could publish a logo to be displayed in the MPEM list, I create a default one and I think I copied a few from the concept images for a few of the plugins that you can see, so that something we will need on the repo too.

 

[sa_ddam213]

The point is: your concept having the MPEM browser and the MPEM UpdaterService are definitely required components. These perfectly fit into a Extensions Management concept, but how do you plan to define dependencies between plugins, additional specific versions or version ranges. This is fundamental for the extension management, and I think here is already a lot of work done by the NuGet.Core.

NuGet packages itself are no executables, these are just zip files having a different file extensions and containing the files that have been defined to be packed into the package of course and the metadata. Using the NuGet core it should be possible to read such metadata applications like the MPEM browser and MPEM Updateservice.
The good thing is the metadata is the same specification inside the nuget package as well as when creating the package or when retrieving the available inforamtion from the nuget gallery (website).

Like I already wrote in the other thread I am very sorry I can not help with working actually on this topic, current, even not on the nuget area, as I am finishing my studies these weeks and still have a lot to do to make it in time, but other than using NuGet for development dependencies I also did not work more with it, yet. So my knowledge about using it in your own application is the same as yours, nevertheless I believe this is the worth to take a look at it even if it takes some time.
I would understand if you don't want to put so much efforts into it when working alone, so it would be great if there are others who could contribute and support you.
I was asked for my opinion and wrote it down, the concerns about Wix and an alternative which comes with a versioning and dependency concept, a package creator, a server component for hosting the packages and a gallery for browsing these online.

It's your decision, you also can go the WiX route and if you prove it's working the team will be happy to have it.

The offer I can make from my side is assisting in any overall questions, do some testing and reviewing concepts and code, but I won't be able to take over any development tasks this year anymore.

I am happy to go the Nuget direction. and as I see it MPEM would:

1. Have a Data connection to both MP and TVServer for installing/updating plugins via the MPEM InstallerService
2. Will be the only way to install plugins(other than a possible GUIWindow version hosted inside MP)
3. If any plugin components need to be installed on a machine other than MP or TVServer the developer could host that installer separately on their own website or add a function inside MPEM to extract that installer to a specified directory for that user to copy to the designated machine to continue installation.

If everyone is happy with those 3 points I think we should just go ahead with the Nuget approach, as like you said the benefits around dependencies versioning is great and if it can be hosted easily on the website side then it seems like a no brainer.

 

[Dadeo]

2. Will be the only way to install plugins(other than a possible GUIWindow version hosted inside MP)

Just to confirm - do you mean no installation/access via web? Personally I have no problem with that since it saves me a lot of work LOL and since your MPEM concept offers everything an online repo does and looks even better imo! However, would that mean no access for 'visitors' to see what extensions MP offers before installing MPEM?

Another question - how will MPEM deal with outdated extensions that are no longer supported? Will there be some mechanism to remove or archive those at some point? If an extension has not been updated for the past 2 years - should we even continue to list it?

 

[Dadeo]

Fell free to edit the Data Xml's add some more plugins for the other category's and the filters will work correctly, there is just no plugins assigenb to those categories.

Yep I figured and I will try - just time is an issue

Package logos is something I forgot to ask about, it would be nice if the plugin designer could publish a logo to be displayed in the MPEM list, I create a default one and I think I copied a few from the concept images for a few of the plugins that you can see, so that something we will need on the repo too.

Yeah MPEI already has an option for Package Icon (as well as Online Icon - I can never remember the diff cuz I just use the same image for both ) and displays a default if not, just as you did. BUT only some extensions provide one and it makes me want to make it a required field! You used the icon from Titan for MovPics, which looks nice, but that does not match what a user sees in Config for Moving Pictures. Never mind we don't even display the MP logo in Config to identify built-in plugins