Blow WindowPlugins.dll to separate plugin DLLs (1 Viewer)

[seco]

For a time I've been thinking that the default plugins that ship with MediaPortal should be single plugin DLLs like 3rd party plugins are. The main reason for this is that I don't use any of these plugins (ok, Home plugin is what I need) and don't want them to be loaded at all. Currently this is not possible since all of these plugins are bundled in one big DLL.

I did a quick and dirty test and removed all default plugin code except Home in WindowPlugins project. Luckily there were only few compilation errors and I managed to create a WindowPlugins.dll which only contains Home (which is required to run MP). Using this custom DLL I didn't see any problems in MP Configuration or running MP. And starting up MP was really fast.

What I'm suggesting would not change anything on the user side, the configuration and all would still work same as before. On the code side this would mean moving the code to separate projects & fixing compile errors (these errors btw indicate a bad design) but in general no new code should be required.

Work in progress:
https://github.com/MediaPortal/Medi...low_windowplugins_dll_to_separate_plugin_dlls

https://issues.team-mediaportal.com/browse/MP1-4315

Binary Installer for TEST
- See attachment
- Please provide all DEBUG logs if you have issues

BUILD
Based on MP 1.6 Final :
[14-01-10 18:05:14] Link: http://tinyurl.com/mqjfv6t

 

[tourettes]

I think it is good idea for two reasons:

1) Speeding up the load time of MP when no extra plugins are loaded (and in worst case even inited)
2) Making the structure a bit cleaner when only one plugin is in a signle dll

I have no clue why they have been combined in the first place - maybe to gain minimal speedup for the startup time when user has all plugins enabled.

 

[jameson_uk]

There is quite a lot of shared code across the various plugins. Not sure that start up of MP / config would be that much quicker (would be interested to see measurements though)

 

[seco]

There is quite a lot of shared code across the various plugins. Not sure that start up of MP / config would be that much quicker (would be interested to see measurements though)

I'm not sure what you mean. Do you mean that plugins are referencing each other (shouldn't be like that)? Also, this isn't all about the speed but making MP to follow it's own plugin architecture.

 

[jameson_uk]

I'm not sure what you mean. Do you mean that plugins are referencing each other (shouldn't be like that)? Also, this isn't all about the speed but making MP to follow it's own plugin architecture.

There is shared code (e.g. a window plugin base class that would require a separate binary (or moving somewhere else with possible added dependencies) and I think there are also some links between the different plugins. It is not ideal but there is a lot of legacy code about...

If you can supply a patch splitting everything into separate binaries without breaking any existing functionality then please do but I am not sure it is worth the time it would take for development and all the regression testing it would be needed.

I do think it is a good idea but I am just not sure of the cost vs benefit.

 

[seco]

I was able to do this properly for Home, Music, and Videos in a few hours so I guess it's doable as long as the plugin code won't depend each other. The biggest problem is to relocate common code like WindowPluginBase and such. I'm not sure if Core (guilib) is the right place for this stuff.

 

[Sebastiii]

Maybe @Deda can have an idea on this ?

 

[Sebastiii]

More i thinking it seems core (guilib) can be a good place
@arion_p what do you think ?

 

[Deda]

Don't know right now, but I know when something sounds easy it became very complicated after. This is too big to just remove them to a separate projects in a few hours and said it's all ok (maybe in certain cases which user use MP, but for many other situations this will be a failure, I can guarantee that). Also this will break 3rd party plugins like FanartHandler...

 

[seco]

Don't know right now, but I know when something sounds easy it became very complicated after. This is too big to just remove them to a separate projects in a few hours and said it's all ok (maybe in certain cases which user use MP, but for many other situations this will be a failure, I can guarantee that). Also this will break 3rd party plugins like FanartHandler...

1. I didn't mean that everything is OK, I just said that it is not impossible task to create a separate projects since the plugins are not that bad and don't depend on each other.
2. Of course it needs a lot of testing since the amount of automated (or any) tests is zero and because of this for the most of the people the refactoring is an impossible idea and a nightmare in any part of MP code.
3. I understand that this breaks a lot of 3rd party stuff which depend on the stuff that is being moved. I guess the compatibility stuff in MP is for cases like this.