MP2 WebServer - Configure MP2, Browse, Edit & Play MediaLibrary, ... (2 Viewers)

[offbyone]

In theory, you can write Javascript to communicate with UPnP - there are some scripts out there. But the question is how big the effort is to do so for this use-case, and if it wouldn't be a lot easier to write a website in a way you already know as website developer

Webserver is probably a strong word for what is currently build into the MP2 Server. It is a very lightweight solution in order to deliver plain and only HTTP. But it is exactly what we needed so far, since UPnP Messages are sent as HTTP

 

[morpheus_xx]

Finally, I saw that there is a branch about integrating Griffin.Webserver into MP2 by @morpheus_xx. Morph, can you explain a bit about the background? What Webserver do we use now?

We are currently using the "HttpServer" project, where Albert did some bugfixes in code (are commented). When I checked for updates, I found the original author now offered the Griffin.WebServer. It is still WiP and not compatible with the MP2 needs. I stopped any work on this part, as the issues I tried to solve were not related to the webserver (see UPnP/cablecard development).

For now I see no real need to look for another webserver (based on current requirements!). Generally spoken, we also should avoid a mixture of to many technologies: MP2 communication uses UPnP (over plain http); TVE35 offers WCF-services (not used for MP2, but i.e. for SetupTV).

P.S. It's also open source: http://aspnetwebstack.codeplex.com/

This one looks very interesting, but as said above, first we would need a real requirement to touch this code (some MP2 modules are tied to HttpServer).

 

[chefkoch]

As the webserver/webstack would not be required for communication between MediaPortal components (MediaPortal.Common), would it be best (or an option in the meantime to prevent code mofifiations/mixture) to include it in a plugin?

 

[MJGraf]

Yep, that's definitely possible. But somehow I'm not yet happy. Putting a separate http server with additional functionality into a plugin means in the end having two different http servers within one application and that sounds to me like a workaround - not the MP2 way of doing thing right...
Maybe it's a better idea to provide a separate webservice plugin, which can then be used for our use case and maybe others as well. I'll try to read a bit about it...
Could someone give me a hint how this would technically work then? Is it correct that we would then have a http server providing a HTML page with JavaScript in it, which would then access the webservice?
Thanks, Michael

 

[Lehmden]

Hi.
If I understand it right there is no easy way to modify the MIAs via the existing HTTP server. Normally only the MP2 server itself is able to modify the MIAs, if I understand this right. We are now looking for a way an external Tool (no matter if it's Browser based or standalone) can modify them and follow the MP2 rules as well...

A Browser based solution has some advantages. First it can be run on any platform. So I can correct (modify) the medialibrary from my Phone/Tab as well as from my laptop or any other PC without the need for an extra installed tool. And I can do some coding on this. But this will need some extras (whatever this may be) added to the Server...

A Standalone Tool probably don't need any modifications on the MP2 Server at all. But this has to be installed on the Server PC, would run only on Windows and probably needs to be written in a language I can't do any coding...

It looks as if this would be a greater task then thought, I'm not sure if it is worth it. In a later Version of MP2 this surely has to be done in the client GUI as it's the place where I can see those needed modifications at first. The scrapper has got a cover in Russian language, but I can't read Cyrillic at all, press few buttons on remote and replace it with a German language cover (Or English or whatever language you prefer...). This is how it should work finally. Errors are unavoidable on any kind of automatic metadata scrapping. So in a final version there definitely has to be an option to correct those errors...

 

[Valk]

Think of the aspnetwebstack as if you're hosting in IIS or apache. It's a full blown asynchronous http hosting server (probably heavily based on IIS) so you could host anything you could host on IIS with the .net framework installed (sorry no php but asp.net is fine ). The only extra effort would be setting up the basic routing (which you have to do hosting in IIS anyway) and off you go.

While it would be nice to have it as a built-in webserver where people just register there routes with it and off they go for now I'd say stick to a plugin and build the interfaces etc. on the basis of merging it in the future to replace the built in server.

Currently there are far to many important jobs to do for the main client that reworking the HTTP server is a low priority, especially considering that neither would have any effect on each other in the slightest.

The benefits of doing this though I see are worth the effort. If we expose a WebAPI which is easy for people to understand how to use for most functions I can see other clients been made for MP2 and rapid integration of devices happening.

If we do it though I'd suggest making a web interface also so people can see something and it feels like a finished product from the start. If it's half finished you'll never shake that feeling in the users minds.

Anyway since I'm ranting now and don't even remember what I've wrote I'll leave it with this. I believe this feature is something MP2 needs before it hits 1.0 even if it is just a plugin but for now the main client comes first .

 

[gibman]

when talking webAPI, you also have the choice of using WCF dataservices (OData).

One place where ODATA owns webAPI is that the client is able to use projections in the queries.
Which has a lot to do with SQL performance.

nice discussion here btw. :
http://stackoverflow.com/questions/9504023/wcf-data-services-odata-vs-asp-net-web-api

here is an example of a query done on the client (for those who haven't seen the syntax):
http://localhost/api/customers?$top=10&orderby=country

So this is a nice cheap way to expose the entire DB.

/gibman

 

[MJGraf]

Lehmden: You are right with everything in your post except this:

But this has to be installed on the Server PC

Since a standalone app would make use of the UPnP infrastructure, you could start it on any computer in your network and it would talk to the MP2 Server via UPnP - just as a MP2 client.

Apart from that I would like to summarize a bit, because I'm still thinking about doing some development in that direction (no promise, more a threat )

HTTP-Server:
We have an inbuilt HTTP-Server but it is quite limited. It can server files via HTTP and is used for the UPnP infrastructure. It cannot be used for any kind of webservice or server-side logic.

WebService:
MP2 currently uses UPnP for the client communication. UPnP could be used to access the MP2 server via JavaScript as well, but this seems to be a bit cumbersome. We don't have a "WebService", yet.
I tried to read a bit about the ones mentioned here, so the following may be wrong - if so, please correct me:
We have two options:
ASP.Net Web Services: From what I read, it is the "older" technology, but constantly enhanced by new features. It provides you with a lot of control over the http-stack, but on the other hand requires a different web-server, such as http://aspnetwebstack.codeplex.com/. This could be implemented completely as a plugin. This is of course the right way in the beginning, but IMHO in the long run, if we go that route, we should think about replacing our current http-server with this one because it doesn't feel right to have 2 different http servers in one product.
It seems still to be the recommended product to use if you're planning to access the service by a mobile device.
WCF Dataservices: This seems to be the newer technology, also requiring less coding (in particular implementing IQueryable). However, one seems to have less control over the http-stack, i.e. this is a "pure Webservice". It seems to offer more control over queries (as pointed out by OffByOne).
Is it correct that this would be "included" in .net4, i.e. we don't need a separate http-Server to host on the plugin? At least this is my impression from the articles I read... [Edit: This is correct as per OffByOne's post below]

Reasons for having a WebService:
From what I can see so far, there are various reasons for having a WebService:

• First of all, I'm still thinking of MP2 a being a multimedia platform. We also have an application on top of this platform (i.e. MP2 Client), but for me it seems crucial that we have a platform on which other applications can built on. Having an XBMC plugin for the MP2 Server? Why not! Writing a Client application for Linux being able to access the MP2 Server (as mentioned in another recent thread)? Go for it. So my understanding of MP2 Server is offering services for applications. If a WebService makes it easier for other applications to access the MP2 Server and we might get a broader user base by having more community developed applications for our MP2 server, then I would say we need it.
• The same applies to applications for mobile devices.
• This thread started with the idea of having a WebSite embedded in MP2 to be able to edit Media Idem Aspects. It seems that such a website would also need some kind of WebService to query and display Media Item Aspects. But it's not only MIAs:
  • I could also imagine to provide a possibility to edit settings of MP2 Server over a Website. The settings could be published via the WebService.
  • The Webservice could also be used to expose some functions which start the transcoding and streaming of Media Items (i.e. MPExtended with WebMediaPortal for MP2).
  • There was also a concept in our Wiki (don't find it right now), where MetadataExtractors need a way of communicating with clients, in particular when they don't find a 100% match, but e.g. two covers that might fit to a song and now you need user interaction for the user to chose the right one. While this may work via the MP2 Client, if we are talking about one single album to be added to the Media Library, the MP2 client GUI and a remote is certainly not ideal, if you import your whole music collection and there may be 100 of such conflicts to resolve. This may also be achieved easier by having a website.

Concept of exposing MIAs
Now back to the idea of exposing MIAs - the rest can be handled later:

First it is IMHO important that we don't expose "the database", but we should expose MIA objects. The reason is that I would like this plugin to be completely independent from the database in the backend of the MP2 server.

Secondly, all the examples I found in the web so far were exposing objects, which they knew the structure about. However, in our scenario, every plugin may add new MIAs to the MP2 system. What I want it that

• a developer, who adds a MIA to the system via a plugin, does not have to take care of this MIA being exposed by a WebService later on, AND
• at the same time such added MIAs automatically being exposed by our WebService (i.e. something like a dynamic exposure of MIAs).

This means that we first need some kind of query like "what kinds of MIAs does this MP2 server handle" and based on the result of this query the consuming application of the Webservice should be able to query different MIA types.

Concept of the MP2 Server Website
First of all I get the feeling that the Website should be a separate plugin from the WebService.
Then the question pops up, which http server we should use. If we can use the already inbuilt http server, we may use WCF for the WebService so that we don't have to include a relatively heavy additional webserver such as aspnetwebstack. However, if the inbuilt http server is not flexible enough for our website anyway and we have to integrate e.g. aspnetwebstack for the Website, we should use this also for hosting either the asp.net WebApi or the WCF service.
Finally, the Website should be extendable by plugins. The thread started with the idea of being able to edit MIAs. But as mentioned above, we could also have this website expose the settings of the MP2 server or resolve conflicts generated by Metatada Extractors.

Overall Concept
The more I think about this, the more I can imagine the following concept:

• We have one main plugin which hosts the aspnetwebstack and a simple WebSite: The Website just displays "Hey, I am your MP2 Server" and has a menu on the left. But the menu doesn't have any item in it, yet.
• Then there is a second plugin providing a WebService. The Webservice (either asp.net WebAPI or WCF) exposes all possible objects of the MP2 server (in the beginning MIAs, later maybe settings, etc.). I think we should keep the webservice in one plugin to have a standard interface of our WebService. [Question: Do you agree? Or should we make the WebService plugin also extendable by other plugins? This may give more flexibility, but on the other hand, every plugin author may be tempted to provide his "own way of accessing MP2 objects without thinking about the right way to do it?] This WebService is hosted in the aspnetwebstack and, hence, this plugin depends on the main plugin. The webservice may be used by any kind of consumer application (mobile device clients, the third kind of plugin below, etc.).
• Finally, we have further plugins filling our main webserver plugin with live. A plugin may add an item to our MP2 Server website's menu and provide the website which is displayed if someone clicks on such menu item. This website may then make use of the webservice provided with the second plugin.

Conclusion / Remaining Questions
Ok, having read my own thoughts, this may be something for the next one or two years instead of the next one or two weeks... But hey, we were talking so much about visions over the last weeks, this may be one of them. But before starting anything, there are still some questions I would like to hear your opinion about:

• Based on the above, I'm leaning towards using ASP.Net WebAPI. I'm not talking about the way to implement it, for now I'm just interested in the following: Is there any kind of consuming application for which WCF would be the only (reasonable) Webservice (Linux? iOS?)? The reason for the question is: If we put so much effort into it, I don't want to realize later that "we cannot build an application for xy, because we used ASP.Net WebAPI instead of WCF" (of course, things are changing quickly in this respect, but the question is about the status as of now).
• Should we make the Webservice as one plugin containing all possibilities to access the MP2 server or should we make it expandable by plugins? What I want to avoid here is that every plugin developer adds its own way of searching for MIAs although it would make more sense to have one single defined Interface to access everything in the MP2 server one may need.
• Is using WCF withough aspnetwebstack and our inbuilt http server for the website a realistic alternative? I.e., are my thoughts above overkill and we can achieve the same result with a much lighter plugin? Or shall we "make it right" and offer the flexibility of aspnetwebstack at the cost of having much more overhead in the beginning?

ok, ready for now - so please share all your thoughts. It is much appreciated and now we are still at a stage where changing the concept is easily possible! Thanks!
Michael

 

[Valk]

ASP.Net web services themselves are older but the WebAPI itself is a new iteration on the idea which feels like a real popular method to use from MS. I agree in the long run it would be good to replace the server with something that has more features such as the aspnetwebstack but I don't see any reason why someone can't use it now and create a plugin for a webservice. Anyone doing it though I'd highly encourage to consider future integration though that should have no real issues I can perceive.

If you wish to use WCF data services they can also be hosted within the WebAPI project so there's no limitation on which way you intend to offer up a service (best of both worlds ).

 

[offbyone]

Is it correct that this would be "included" in .net4, i.e. we don't need a separate http-Server to host on the plugin?

That is correct! It's in the framework and don't need any special component additionally. You can host a normal WCF Service or a WFC Data Service (Odata). The later is a publicy specified protocol which can be used by many clients easily (Javascript libraries like Sencha, which will allow creating HTML apps for any browser and even making it into an iOs or Android app easily).