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.