Reply to thread

Message

Aaah... you've been looking at the code, huh?

Ok, I think its time for me to spill the beans on how the whole thing works (some people may have worked it out already as most of the source code was included)...

The web interface works by talking to a web service, which in turn talks to the plugin which then passes the message onto MP.

Now, some may ask why there are so many steps just to pass a message along. The answer is because the web interface was written in PHP, while the plugin was written in VB.NET. In order to bridge the .NET and PHP gap, the web service has to be there as web services are standardised. It also makes it much easier for others to use the plugin over the network, but that wasn't the primary reason.

PHP couldn't talk to the plugin directly because the plugin uses .NET remoting for communication - a .NET only technology. The web service converts standard web service talk to a .NET remoting message for the plugin. Therefore, if you are writing a .NET app, if performance is vital, talking directly to the plugin is much better (in technical terms, there are less serialisation/deserialisation processes).

The code to talk to the plugin was included in the setup (look in the MPWebControl\htdocs\MPExtControlWS folder).

I would be happy to share the code for the plugin itself, but there are two things:
1. I wrote it in VB.NET and not C#. VS.NET will cope with this without a problem (provided you've installed VB.NET) however other compilers will complain. Maybe include it seperately from the main code (e.g. outside the mediaportal folder in CVS).
2. It would be great if this was in the CVS and I had access to it because I'm planning on making a PPC remote app (not web page) and that would require the addition of a few more functions. I'll have to wait until I get my PPC though...

If its no problem, PM me or post back here and I'll give you the code.

BTW, in the new build of the web interface, I have limited access to the web service to ONLY internal network devices for security purposes, i.e. the web service is not accessible from the internet.

Sam

<blockquote data-quote="samuel337" data-source="post: 7694" data-attributes="member: 10347">Aaah... you've been looking at the code, huh? Ok, I think its time for me to spill the beans on how the whole thing works (some people may have worked it out already as most of the source code was included)...The web interface works by talking to a web service, which in turn talks to the plugin which then passes the message onto MP.Now, some may ask why there are so many steps just to pass a message along. The answer is because the web interface was written in PHP, while the plugin was written in VB.NET. In order to bridge the .NET and PHP gap, the web service has to be there as web services are standardised. It also makes it much easier for others to use the plugin over the network, but that wasn't the primary reason.PHP couldn't talk to the plugin directly because the plugin uses .NET remoting for communication - a .NET only technology. The web service converts standard web service talk to a .NET remoting message for the plugin. Therefore, if you are writing a .NET app, if performance is vital, talking directly to the plugin is much better (in technical terms, there are less serialisation/deserialisation processes).The code to talk to the plugin was included in the setup (look in the MPWebControl\htdocs\MPExtControlWS folder). I would be happy to share the code for the plugin itself, but there are two things:1. I wrote it in VB.NET and not C#. VS.NET will cope with this without a problem (provided you've installed VB.NET) however other compilers will complain. Maybe include it seperately from the main code (e.g. outside the mediaportal folder in CVS).2. It would be great if this was in the CVS and I had access to it because I'm planning on making a PPC remote app (not web page) and that would require the addition of a few more functions. I'll have to wait until I get my PPC though...If its no problem, PM me or post back here and I'll give you the code.BTW, in the new build of the web interface, I have limited access to the web service to ONLY internal network devices for security purposes, i.e. the web service is not accessible from the internet.Sam</blockquote>

[QUOTE="samuel337, post: 7694, member: 10347"] Aaah... you've been looking at the code, huh? Ok, I think its time for me to spill the beans on how the whole thing works (some people may have worked it out already as most of the source code was included)... The web interface works by talking to a web service, which in turn talks to the plugin which then passes the message onto MP. Now, some may ask why there are so many steps just to pass a message along. The answer is because the web interface was written in PHP, while the plugin was written in VB.NET. In order to bridge the .NET and PHP gap, the web service has to be there as web services are standardised. It also makes it much easier for others to use the plugin over the network, but that wasn't the primary reason. PHP couldn't talk to the plugin directly because the plugin uses .NET remoting for communication - a .NET only technology. The web service converts standard web service talk to a .NET remoting message for the plugin. Therefore, if you are writing a .NET app, if performance is vital, talking directly to the plugin is much better (in technical terms, there are less serialisation/deserialisation processes). The code to talk to the plugin was included in the setup (look in the MPWebControl\htdocs\MPExtControlWS folder). I would be happy to share the code for the plugin itself, but there are two things: 1. I wrote it in VB.NET and not C#. VS.NET will cope with this without a problem (provided you've installed VB.NET) however other compilers will complain. Maybe include it seperately from the main code (e.g. outside the mediaportal folder in CVS). 2. It would be great if this was in the CVS and I had access to it because I'm planning on making a PPC remote app (not web page) and that would require the addition of a few more functions. I'll have to wait until I get my PPC though... If its no problem, PM me or post back here and I'll give you the code. BTW, in the new build of the web interface, I have limited access to the web service to ONLY internal network devices for security purposes, i.e. the web service is not accessible from the internet. Sam [/QUOTE]