home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
MediaPortal 1 Plugins
Webinterface plugin
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="samuel337" data-source="post: 7694" data-attributes="member: 10347"><p>Aaah... you've been looking at the code, huh? </p><p></p><p>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)...</p><p></p><p>The web interface works by talking to a web service, which in turn talks to the plugin which then passes the message onto MP.</p><p></p><p>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.</p><p></p><p>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).</p><p></p><p>The code to talk to the plugin was included in the setup (look in the MPWebControl\htdocs\MPExtControlWS folder). </p><p></p><p>I would be happy to share the code for the plugin itself, but there are two things:</p><p>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).</p><p>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...</p><p></p><p>If its no problem, PM me or post back here and I'll give you the code.</p><p></p><p>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.</p><p></p><p>Sam</p></blockquote><p></p>
[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]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Plugins
Webinterface plugin
Contact us
RSS
Top
Bottom
