New Webinterface (2 Viewers)

[Bram]

I read today Microsoft wants to integrate php support in .NET. That would be realy nice

 

[Maschine]

If you're going the ASP.NET route then I'm sure I'll contribute also.

I'd hope you would say that, my friend Welcome on board!

 

[misterd]

Hi everyone,
I also just want to share some of my thoughts. I think the programming language of the web interface should be irrelevant and it is more important that MP gets an universal remote interface like MJGraf already mentioned.

Therefore I would prefer that MP has an integrated web service. The main advantage will be that everyone can write his own web interface, standalone application, PDA client etc. The only thing that is needed for such a piece of software is a library for your programming language for using web services. For example could MP use the cassini web server to provide this web service and since cassini is only a small library there is no need for additional setup. I know that cassini doesn't provide all features of an Apache like htaccess, but I think that it has everything that is needed to provide such an web service. Perhaps it will be also possible to integrate such an web service in the TV server. Perhaps it will be possible to combine the ressources of MPW and the MPBlue PPC client for this web service.

As I said that are only my thoughts when reading this thread and looking into the current sources of MPW.

Regards,
MisterD

 

[Bram]

I think you mean the resources of the ECP2 plugin and MPBlue PPC. MPW uses the ECP2 plugin for comunication with MP.
I totaly agree there should be a universal interface to keep the remote part flexible in the future. The disadvantage would be performance loss I guess?

 

[misterd]

This exactly what I mean. MPBlue PPC has it own plugin to control MP and as far as I know it uses .NET remoting to control MP.
In MPW it is a little bit more complicated. The PHP part comunicates with an web service written in ASP.NET. And this web service also uses .NET remoting to communicate with MP and ECP2 Plugin only allows .NET remoting. So MPW has an unnecessary overhead.
So it would be better if MP has only one remote interface and I think that a web service would be the best solution, because many programming languages support web services.

 

[samuel337]

I read today Microsoft wants to integrate php support in .NET. That would be realy nice

Not sure about that, but there's been a .NET implementation of PHP out for a while, called phlanger - http://www.php-compiler.net/.

This exactly what I mean. MPBlue PPC has it own plugin to control MP and as far as I know it uses .NET remoting to control MP.
In MPW it is a little bit more complicated. The PHP part comunicates with an web service written in ASP.NET. And this web service also uses .NET remoting to communicate with MP and ECP2 Plugin only allows .NET remoting. So MPW has an unnecessary overhead.
So it would be better if MP has only one remote interface and I think that a web service would be the best solution, because many programming languages support web services.

However, the advantage of my architecture is that it does not require the web service to be running on every client. Each client will have to run the ECP2 plugin, however, only one client/server will have to run the web service, which will automatically route the requests to the appropriate machine. This should make it much easier for web service users to communicate with MP.

Note that MPBlue actually uses .NET remoting in its web service form. That is, the .NET remoting part actually acts as a SOAP web service. The downside is that without a 'broker', each client will have to run the MPBlue server plugin and the web service (and also that generics aren't supported).

I don't believe that there is a significant performance lag with using .NET remoting coupled with a web service. Another advantage of this is that .NET applications can communicate directly with MP using MP objects without having to serialise and deserialise to and from XML (improving performance). This is in fact the main performance lag - the serialisation of MP objects into XML by the web service and unfortunately cannot be helped given the nature of web services.

MPBlue devs - please don't take this the bad way, in fact I'd be quite interested in seeing what you guys are doing to handle the new client/server configuration. Do correct me if I have the facts above wrong.

Sam

 

[misterd]

However, the advantage of my architecture is that it does not require the web service to be running on every client. Each client will have to run the ECP2 plugin, however, only one client/server will have to run the web service, which will automatically route the requests to the appropriate machine. This should make it much easier for web service users to communicate with MP.

That's right. This is really an advantage of your architecture.

I don't believe that there is a significant performance lag with using .NET remoting coupled with a web service. Another advantage of this is that .NET applications can communicate directly with MP using MP objects without having to serialise and deserialise to and from XML (improving performance). This is in fact the main performance lag - the serialisation of MP objects into XML by the web service and unfortunately cannot be helped given the nature of web services.

But in fact .NET remoting has also to serialise and deserialise the MP objects for transferring them to another process or other computer. Sure the performance is better than the performance of serialising and deserialising to and from XML.
Therefore I would prefer simple new objects only for the web service, which are not so complicated as MP objects. Just a simple interface with simple objects. This make it also more easy for the clients.
And don't take this the bad way, it is only my opinion and experience with MPW when I tested it a half year ago.
If I time the time at weekend, I will try to make some tests with cassini and web services.

MisterD

 

[samuel337]

I don't believe that there is a significant performance lag with using .NET remoting coupled with a web service. Another advantage of this is that .NET applications can communicate directly with MP using MP objects without having to serialise and deserialise to and from XML (improving performance). This is in fact the main performance lag - the serialisation of MP objects into XML by the web service and unfortunately cannot be helped given the nature of web services.

But in fact .NET remoting has also to serialise and deserialise the MP objects for transferring them to another process or other computer. Sure the performance is better than the performance of serialising and deserialising to and from XML.
Therefore I would prefer simple new objects only for the web service, which are not so complicated as MP objects. Just a simple interface with simple objects. This make it also more easy for the clients.

I left out the extra serialise/deserialise step for clarity, but you're right.

Anyway, the system you described above is how MPBlue does it. Problem is, if at any time the MP devs decide to change something which changes how the MP equivalent object works, the web service would either result in an error, or malfunction. (Unless you access the database directly via SQL, which then makes you vulnerable to database schema changes.) In any case, there will probably be need for a new version, which needs to be tested all over again etc.

That said, because MP's music database class is in such a mess because direct SQL statements are used instead of the DAL, I've had to create some new objects too for specific information (e.g. for things like Album and Artist) that get the information by accessing the database directly.

In the end its a compromise between making things easier for the .NET devs (by using generics etc.) or making things more accessible to everyone (e.g. using arrays instead of generic lists).

Some profiling of this would be interesting.

Sam

 

[samuel337]

Just a bit of a heads up for those interested:

Windows Vista Home editions (Basic and Premium - add an N if you're in Europe) will not have IIS 7.0 included. Only Windows Vista Ultimate will, so I guess this is another vote for an inbuilt web server.

I personally have no real need for Ultimate, maybe apart from RDC, but that's not enough of an incentive. Home Premium will be fine for me, but I'll probably get Ultimate anyway, because I like having the latest and the greatest

Here's the comparison matrix for the various editions for those interested:
http://www.istartedsomething.com/wp-content/uploads/2006/11/upgrade.gif

Sam

 

[Bram]

And also, for my HTPC I realy like a machine that runs only what is needed. SO Ultimate is way overdone. Pretty significant information indeed.
Any idea how far you can go with Apache with ASP support? Would it be possible to use the .NET stuff you'd need?

One other, probebly completely rediculous, idea. What about running a centralised server? You create an account on this server, enter your IP in the webapplication and allow it to connect thrue your router or modem.
The advantages are that it'll keep MP more compact and will reduce used recources. Also, it can be completely platform independant, offers the possebility to obtain a lot of statistics and maybe even use it to collect errorlogs which can make debugging and further development much easier.
While thinking about this... I keep comming up with ideas that could be done thrue a centralised server.
Disatvantages.... It costs money and might influence performance a bit.

As I said....probebly completely rediculous.