Canada
I would love to see the MPW seamlessly run under IIS.
New Webinterface (2 Viewers)
- Thread starter Chris84
- Start date
- Thread starter
- #12
And i don't like IIS.
Although i'm a friend of windows and all it's easy to use surfaces, i never got warm with IIS. Maybe because in the short time of usage it got nimda to my network. I'm a friend of the good old apache. Every thing to configure in one file, thats how i need it. I always ran into trouble trying to use php with IIS. It's a long time ago i used it last time, but i think i'll stay at apache.
Although i'm a friend of windows and all it's easy to use surfaces, i never got warm with IIS. Maybe because in the short time of usage it got nimda to my network. I'm a friend of the good old apache. Every thing to configure in one file, thats how i need it. I always ran into trouble trying to use php with IIS. It's a long time ago i used it last time, but i think i'll stay at apache.
I used an installer to get PHP running under IIS and had no problems whatsoever. I'm definitely not an MS fanboy, but I found IIS much easier to setup than Apache.
Chris84:
Yes its not very clear what the PHP files do - reason explained in previous post. To find out all that the web service is capable of, navigate to http://localhost:81/MPExtControlWS/service.asmx (replacing localhost with the name of your MP computer/IP address if you're using another computer).
Also note that there is a new version of the web service available in the mp-webinterface SVN repository that implements a lot more too. If you want, I can cut and paste a list of all the functions available - data is returned in XML format so it should be pretty easy to use for anyone using any language.
As for the dotnet component taking up a lot of memory, that's unfortunate as like Chris84, I like apache as you can configure it using a text file. I love IIS however, for its UI. So if I can get the best of both worlds, it'd be awesome. But that's the reason IIS is not used - its difficult to automate configuration. Whilst Khris you may be able to configure it easily, I'm sure its not as easy for others.
I'll be looking into an alternative for the dotnet apache module soon - I'm thinking of implementing a small web server in the ECP2 plugin, so that the web service is hosted by .NET natively, instead of using apache as the middle-man. That should eliminate all the performance problems. Also note that the last time I checked, the apache dotnet module is not .NET 2.0 compatible (while the code I'm using is .NET 2.0) so I don't like the situation very much. It will change soon
Sam
Yes its not very clear what the PHP files do - reason explained in previous post. To find out all that the web service is capable of, navigate to http://localhost:81/MPExtControlWS/service.asmx (replacing localhost with the name of your MP computer/IP address if you're using another computer).
Also note that there is a new version of the web service available in the mp-webinterface SVN repository that implements a lot more too. If you want, I can cut and paste a list of all the functions available - data is returned in XML format so it should be pretty easy to use for anyone using any language.
As for the dotnet component taking up a lot of memory, that's unfortunate as like Chris84, I like apache as you can configure it using a text file. I love IIS however, for its UI. So if I can get the best of both worlds, it'd be awesome. But that's the reason IIS is not used - its difficult to automate configuration. Whilst Khris you may be able to configure it easily, I'm sure its not as easy for others.
I'll be looking into an alternative for the dotnet apache module soon - I'm thinking of implementing a small web server in the ECP2 plugin, so that the web service is hosted by .NET natively, instead of using apache as the middle-man. That should eliminate all the performance problems. Also note that the last time I checked, the apache dotnet module is not .NET 2.0 compatible (while the code I'm using is .NET 2.0) so I don't like the situation very much. It will change soon
Sam
- Thread starter
- #15
Another question:
The new TV Engine is based on a Client/Server arcitecture. So the client gets all the required data from the server. Within this data should be a lot of data required for the WI.
The actual Idea of getting the data is: You connect to the webserver, the webserver starts up an Dot Net Application, translating between MP Database and php Script.
With the new Client/Server Application this should be unimportant overhead. If there are documented interfaces to describe the client/server Communication, we should be able to write a native php client to get all the required data and also send them back.
You no longer need to start up a seperate Application, presenting the data cause with the new version there is allways running a server able to deal with the required infos. Maybe you have to tune up some interfaces, but writing this additional server seems to be for me a work done two times.
Btw. thx for the link, the doc is a good help.
The new TV Engine is based on a Client/Server arcitecture. So the client gets all the required data from the server. Within this data should be a lot of data required for the WI.
The actual Idea of getting the data is: You connect to the webserver, the webserver starts up an Dot Net Application, translating between MP Database and php Script.
With the new Client/Server Application this should be unimportant overhead. If there are documented interfaces to describe the client/server Communication, we should be able to write a native php client to get all the required data and also send them back.
You no longer need to start up a seperate Application, presenting the data cause with the new version there is allways running a server able to deal with the required infos. Maybe you have to tune up some interfaces, but writing this additional server seems to be for me a work done two times.
Btw. thx for the link, the doc is a good help.
I just briefly checked out the code and it seems like they're using .net remoting over TCP. This should mean that the data is serialised in binary too, making it harder for PHP to decode (and even once it is decoded, you have to decode the structures as well).
The main reason for using binary as far as I can see is that Microsoft, in their infinite wisdom, decided that you cannot serialise generics using XML/SOAP (which is coupled with communication over HTTP). I ran into this problem as well with my ECP2 plugin, hence why there's a web service to expose this properly via SOAP.
If they were using XML/SOAP over HTTP for the remoting bit there would be some hope of PHP being able to communicate directly via SOAP, but as they're not I think it would be fairly difficult (I'm not exactly sure what PHP is capable of, so take this with a grain of salt).
Your other option is to communicate using COM in PHP. Not sure if it works currently, but it should with a few changes in code. But with this option you probably still have to decode and convert the .NET objects to PHP objects.
Sam
The main reason for using binary as far as I can see is that Microsoft, in their infinite wisdom, decided that you cannot serialise generics using XML/SOAP (which is coupled with communication over HTTP). I ran into this problem as well with my ECP2 plugin, hence why there's a web service to expose this properly via SOAP.
If they were using XML/SOAP over HTTP for the remoting bit there would be some hope of PHP being able to communicate directly via SOAP, but as they're not I think it would be fairly difficult (I'm not exactly sure what PHP is capable of, so take this with a grain of salt).
Your other option is to communicate using COM in PHP. Not sure if it works currently, but it should with a few changes in code. But with this option you probably still have to decode and convert the .NET objects to PHP objects.
Sam
- Thread starter
- #17
Ok, no good news. The dream of an easy php script doing all the work seems to die. Decoding the binary structure with php seems to be impossible to us or is just a bit to complex and timewasting for saving some bytes of memory.
But there must be a way, without using asp.net on Apache. At study actualy i'm writing an webinterface for a robot. Diffrent implementation but identical problem.
PHP's possibilitys to communicate with RS232 is limited, so we also have to implement a translator.
Our first tries are to do this by a short C program executed by PHP. Why not doing the same here. Writing a small tool, able to give back the required data, controled by some starting parameters. Should be faster than the Apache Dot.Net implementation and all the resources should be given free after finishing its job.
Btw. SOAP is a good idea, to create an open standard Communication. So if there are a lot of programs communicating with each other. But SOAP has also a big disadvantage. It's blowing up the transfered data up to 25 times and takes a lot of CPU time to encode/decode compared with other methodes of data exchange.
A disadvantage of not using soap is: We have to define the structure of data, before starting and will be fixed to this structure.
I hope you don't get me wrong. Even if it sounds a bit like criticising a lot of the done work, it's not my concern to talk everything existing bad. I'm simply new to this and want to give some startings for discussion, maybe you had a lot of my ideas earlier and dropped same due to an good reason.
Btw. internet is a nice development, but communication is slow, if both communication partners are living on the other side of planet earth.
So long
Chris84
But there must be a way, without using asp.net on Apache. At study actualy i'm writing an webinterface for a robot. Diffrent implementation but identical problem.
PHP's possibilitys to communicate with RS232 is limited, so we also have to implement a translator.
Our first tries are to do this by a short C program executed by PHP. Why not doing the same here. Writing a small tool, able to give back the required data, controled by some starting parameters. Should be faster than the Apache Dot.Net implementation and all the resources should be given free after finishing its job.
Btw. SOAP is a good idea, to create an open standard Communication. So if there are a lot of programs communicating with each other. But SOAP has also a big disadvantage. It's blowing up the transfered data up to 25 times and takes a lot of CPU time to encode/decode compared with other methodes of data exchange.
A disadvantage of not using soap is: We have to define the structure of data, before starting and will be fixed to this structure.
I hope you don't get me wrong. Even if it sounds a bit like criticising a lot of the done work, it's not my concern to talk everything existing bad. I'm simply new to this and want to give some startings for discussion, maybe you had a lot of my ideas earlier and dropped same due to an good reason.
Btw. internet is a nice development, but communication is slow, if both communication partners are living on the other side of planet earth.
So long
Chris84
The reason I was considering a web service to proxy the remoting commands to the TV server was the exact reason mentioned above that it is transported in binary and therefore I would not be able to use it with Python on the Xbox with out a lot of hassel.
IIS has come a long way in version 6 and has been completely remodelled from previous versions so security should not be as big an issue as it was in earlier versions. That said I don't think we can use IIS as all the poor people out there running XP Home should not be stopped from running the web interface.
Running a webserver with .Net in process is very easy and a basic unthreaed version can be written in less that 100 lines of code. Cassini is an advanced open version of this, see here for details http://msdn.microsoft.com/msdnmag/issues/04/12/ServiceStation/
I personally think that working with Asp.Net instead of PHP for the interface is the right choice due to the fact that the rest of MP is C# .Net and the fact that you can code Asp.Net so rapidly. I have developed in both PHP (mostly v4) and Asp.net and Asp.net has it all won for custom controls through inheritance and ease of binding controls to data.
Also running the webserver in process would mean that we have easy control over it form within MP and would make installation a cake walk compared to the current MPW install.
Anyway there my thoughts please continue with this discussion as I think we may ne onto something here.
IIS has come a long way in version 6 and has been completely remodelled from previous versions so security should not be as big an issue as it was in earlier versions. That said I don't think we can use IIS as all the poor people out there running XP Home should not be stopped from running the web interface.
Running a webserver with .Net in process is very easy and a basic unthreaed version can be written in less that 100 lines of code. Cassini is an advanced open version of this, see here for details http://msdn.microsoft.com/msdnmag/issues/04/12/ServiceStation/
I personally think that working with Asp.Net instead of PHP for the interface is the right choice due to the fact that the rest of MP is C# .Net and the fact that you can code Asp.Net so rapidly. I have developed in both PHP (mostly v4) and Asp.net and Asp.net has it all won for custom controls through inheritance and ease of binding controls to data.
Also running the webserver in process would mean that we have easy control over it form within MP and would make installation a cake walk compared to the current MPW install.
Anyway there my thoughts please continue with this discussion as I think we may ne onto something here.
- Thread starter
- #19
Ok slowly the puzzle starts to grow
So the proxy is not only used for the Webinterface, but also for other services like your XBOX. Then we have to stay at an webbased translator and other ideas are no longer helpfull. (Exept for some very crazy constructions, i don't think they where usefull)
At this point i merge our outcomes, to give a short overview:
Finally i find out a lot of the listed points are only to decide by developers, the pros and cons for a special decision are small, so it should be up to the developers deciding which platform and script language they prefer.
Additional comments are welcome.
So the proxy is not only used for the Webinterface, but also for other services like your XBOX. Then we have to stay at an webbased translator and other ideas are no longer helpfull. (Exept for some very crazy constructions, i don't think they where usefull)
At this point i merge our outcomes, to give a short overview:
Way of getting the required data:
Direct connection with the server seems to be impossible due to binary data exchange.
Proxy based on an application executed by the script or app that needs the required data is seperated, cause we need remote services for platforms not supporting dot net.
There seems to be no way without using some dot net scripts presented by an webserver.
What httpd to use:
ISS is useless, if we want to serv XP Home users, also hard to auto configure via install.
cassini, small and good (i never used it so i have no position) What about php support by cassini??
Apache, fully developed, easy to configure by install routine, bad performance in using Dot net scripts
What scipt language to use?
dot net, also used by our proxy/translator, good support by cassini?(i never used, so had to learn and so due to time limitations i wouldn't be withhin the crew.)
php, identical to the actual, well supported by Apache
Finally i find out a lot of the listed points are only to decide by developers, the pros and cons for a special decision are small, so it should be up to the developers deciding which platform and script language they prefer.
Additional comments are welcome.
Here's something you guys should take a look at:
http://asciiexpress.com/webguide/WebGuide4/tabid/60/Default.aspx
More screenshots here:
http://www.theunwired.net/?itemid=3414
Granted it costs money for all features, but its still way ahead of anything that we have, or MythWeb for that matter. It even has PDA browsing support.
Sam
http://asciiexpress.com/webguide/WebGuide4/tabid/60/Default.aspx
More screenshots here:
http://www.theunwired.net/?itemid=3414
Granted it costs money for all features, but its still way ahead of anything that we have, or MythWeb for that matter. It even has PDA browsing support.
Sam