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
Development
Improvement Suggestions
Caller ID / ADSL
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: 8033" data-attributes="member: 10347"><p>I agree that method one is not really ideal, but .net does provide a very nice filesystemwatcher class that does the 'watching' work for you.</p><p></p><p>Web services - there is a web service running in MP if you install the webscheduler plugin. This method is definitely workable - your callerID detection app would call the web service when a call is detected, passing on the information. The web service would then in turn notify MP.</p><p></p><p>TCP and .net remoting - .net remoting is basically TCP, but more advance and programmatically-sided. All .net remoting is is that you can 'remote' a DLL file so that an external app can call on the DLL file which is already running. What's really happening behind the scenes is that .net turns the DLL into binary or text, transports it to the caller, turns it back into a DLL, the caller makes the call, and .net again converts it to binary or text, transports it back to the 'server' or the running instance of the DLL, converts it back into a DLL and executes the command called. It can do the transporting over TCP or HTTP.</p><p></p><p>I'm sure all that sounds confusing - for simplicity, think of .net remoting as a like a web service except without the web service web interface and all the hosting things that come with it. It is a .net only technology, and performance-wise its better than web services.</p><p></p><p>If you're already familiar with transporting messages over TCP, then by all means do that - I don't know much about that.</p><p></p><p>Anyway, its up to you which way you go.</p><p></p><p>Sam</p></blockquote><p></p>
[QUOTE="samuel337, post: 8033, member: 10347"] I agree that method one is not really ideal, but .net does provide a very nice filesystemwatcher class that does the 'watching' work for you. Web services - there is a web service running in MP if you install the webscheduler plugin. This method is definitely workable - your callerID detection app would call the web service when a call is detected, passing on the information. The web service would then in turn notify MP. TCP and .net remoting - .net remoting is basically TCP, but more advance and programmatically-sided. All .net remoting is is that you can 'remote' a DLL file so that an external app can call on the DLL file which is already running. What's really happening behind the scenes is that .net turns the DLL into binary or text, transports it to the caller, turns it back into a DLL, the caller makes the call, and .net again converts it to binary or text, transports it back to the 'server' or the running instance of the DLL, converts it back into a DLL and executes the command called. It can do the transporting over TCP or HTTP. I'm sure all that sounds confusing - for simplicity, think of .net remoting as a like a web service except without the web service web interface and all the hosting things that come with it. It is a .net only technology, and performance-wise its better than web services. If you're already familiar with transporting messages over TCP, then by all means do that - I don't know much about that. Anyway, its up to you which way you go. Sam [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Improvement Suggestions
Caller ID / ADSL
Contact us
RSS
Top
Bottom