Developer point of view

[LightGlitch]

Hi,

I’m going to give a developer point of view so I’m not going to talk about missing features or UI problems.

I see that you have based media portal development in the sharp develop core and I think that was a nice idea. You also did a great job adapting and extending it to support all the needs of the MP, the changes are so many that’s not even possible to compare it with the original sharp develop core (Great Work!!).

My only critic is the message system. The one that you had implemented in the first version of infinity (mp-xaml-experiment at svn) was much cleaner and nicer.
For me the best option would the first version with one change regarding the way the messages are publish and subscribe. Instead of using meta-information I would use plugin xml for these declarations. By using the xml the developers don’t need to search the plugins source code to know which messages they raise.
This problem still exists in current version.


Another point that I would to give my opinion is the base architecture of MP. If you are making it from scratch why not use the client/server approach? For me MP would a killer app if it was like this:

MP Servers

- Master Server:

o All information passes by this server using a generic message system
o Only this server have access to the database
o The plugins are installed only in this server and then are propagated using the generic message system to the slave servers and clients that support this

- Slave Servers:

o This are only used to stream all the media and relief the master server
o They download the plugins that support slave server from the master

All servers have access to the media resources (movies, music and tv boards) and everything is streamed, the clients don’t have direct access to media resources.

MP Clients

The MP clients should be thin clients. By using this approach is easier to manage and update several clients. Each client downloads from the master server what needs to execute (base) and the plugins that have support for that client. If there’s a new version of the base or any of the plugins downloads it again.
You can also have clients that don’t download anything is useful for cell phones that have some limitations.

MP Plugins

MP Plugins are boxes that contain several packages. Each package is destined to a section of MP. For example we can have a plugin that have:

Server package (Master and slave support if needed)
Windows Client Package
Linux Client Package

None of the packages is mandatory and note that each client package can be implemented in any language as long as the correspondent client knows what to do with it.

The communications (Generic Message System) could be implemented using WCF that allows several binding for the same service and we can have support for .net tcp, json, webservice, etc.

Check the image attached for a graphical view (very simple).


I hope my opinion can be useful in anyway and keep up the good work.

PS: Sorry for the long post.

[frodo]

My only critic is the message system. The one that you had implemented in the first version of infinity (mp-xaml-experiment at svn) was much cleaner and nicer.

Well the reason we choose & implemented this one is the following
The first version of infinity had type-safe messaging. While this sounds nice you create a dependency at compile time between the sender and the receiver.
So if plugin A wants to receive message from plugin B then plugin A needs to know about plugin B at compile time
These dependencies are unwanted since both plugin A and plugin B can be written by 2 different 3th party developers. So if the author of plugin B creates a new verion he 'breaks' plugin A
and the author of plugin A must re compile & redistribute a new version too

By sending a generic message with meta data between plugins & core we avoid these hard-coded dependencies
and plugin A will keep working, even when there is a new version installed of plugin B

Another point that I would to give my opinion is the base architecture of MP.

The base architecture we have now allows to write client & servers
In fact it is planned to create a MP-II server which has no graphical GUI and will serve any media
, including tv to MP-II and other clients (which do have a graphical GUI)


Frodo






Another point that I would to give my opinion is the base architecture of MP. If you are making it from scratch why not use the client/server approach? For me MP would a killer app if it was like this: