Use WebService between Server and Client (1 Viewer)

[gljubojevic]

1) VS 2005 uses his own web server to debug web applications or a web service. This has nothing to do with hosting a web service inside a EXE. The XP-Version (Home, Profesional) is not an issue here because you can host a web service even on XP home without having any kind of Web Server installed.

This is nice, I did't know that I can host web service in EXE that is great!
I guess I didn't done my homework ..

2) Media Portal does not need to be ported to the .NET Framework 3.0 because the new Framework is based on the CLR 2.0. The .NET Framwork 3.0 is the .NET Framework 2.0 plus WCF and some other "Libraries". So It's not really a new version and Media Portal will run fine on V3.0 without any changes or recompilation.

Well FW1.1 -> FW2.0 was huge change especially in web part, at least untill web application project was re introduced, before that porting old web application to FW 2.0 was close to impossible .. (I have full time job as web developer).
That is my main reason to be very cautious to all new technologies MS advertises.

3) With WCF you can switch with a config parameter between Web Services for compatibility or Binary Format (comparable with remoting) for best speed. Code changes are not requred so the user can decide what to use. Using WCF you get the best of both worlds.

Aynway since other members mentioned cross platform I would stick to standard soap, that would hopefully enable e.g. MythTv to access Media Portal TvServer and vice versa. It would be nice to have plugins on MP for accesing MythTv and MP for accesing MythTv

Have a nice day!

gljubojevic

 

[chrispi]

Solid reply there

I am going to look into using a plain WS then - purely for platform compatability. WCF is Windows only atm (I think) so I want to create a purely open solution.

Yes, WCF is Windows only but so is Media Portal.

You can host a Web Service with WCF in the TV Server and consume it by any Web Service capable platform (e.g. Unix, Mac, Windows CE, SybioOS, ...).

This is the whole idea behind web services.

Regards,
Christoph

 

[chrispi]

Well FW1.1 -> FW2.0 was huge change especially in web part, at least untill web application project was re introduced, before that porting old web application to FW 2.0 was close to impossible .. (I have full time job as web developer).
That is my main reason to be very cautious to all new technologies MS advertises.

This is true for the switch from V1.1 to V2.0 but not for v2.0 to v3.0. When you install Framework 3.0 the Framwork V2.0 is installed first. After this the WCF assemblies are added. So .NET 3.0 is .NET 2.0 with some new assemblies.

Indigo (WCF) and Avalon (WPF) was introduced 2 years ago for Windows Vista. They decided to make it backwards compatible to Windows XP and had to find a name for this. Unluckily they choosed ".NET Framework 3.0" for marketing reasons.

.NET Framework 3.0 is:

1) NET Framework 2.0
2) WCF (former Indigo)
3) WPF (Windows presentation Foundation, former Avalon (has all this XAML stuff))
4) WF (Windows Workflow Foundation)

It is true that you have to be careful with new technologies but the current use of remoting in the TV server is outdated. I think we both agree on this. And if you want to host a web service in XP home without IIS you HAVE to go with WCF (or use the even more outdated Web Service Extension).

From my experience WCF works very well. As I posted before my company is currently developing a business solution with WCF for allmost a year and we do not have any special problems.

Aynway since other members mentioned cross platform I would stick to standard soap, that would hopefully enable e.g. MythTv to access Media Portal TvServer and vice versa. It would be nice to have plugins on MP for accesing MythTv and MP for accesing MythTv

WCF is standard SOAP. So this schould not be an issue.

Regards,
Christoph

 

[richbayliss]

Time to code some WCF then

 

[thechad]

Are you planning to code a replacement for the current remoting solution or a TV server plugin with just some of the required features to control the TVServer.

 

[richbayliss]

Just a plugin - makes it easier to have releases.

 

[richbayliss]

having looked into WCF - I am going to utilise a simple TCP based comms routine.

Essentially - send text down a TCP connection, and get a response.

Example: sending "timeshift channel bbc_one\r\n" would return either the RTSP stream name, OR "error: error messag here"

Hopefully simple enough

 

[drfonz]

The way I see it, if you want quick turn around time on the development front (and you have and IIS-enabled server) you're safest bet is WS on .Net 2.0.

With a bit more time (learning curve), WCF on .Net 3.0 sounds like the perfect candidate for the TV Server side of things, because as it was said it can be made to use standard WS upstream, so as far as the client is concerned, it's talking to a standard Web Service.

Now, creating a simple communications protocol talking over TCP is definitely a simple approach which will be cross-platform as long as the protocol is well defined. The main issue I see with this, is that you have to do this from scratch and you have to ensure a multi-client, multi-connection paradigm is implemented. This is precisely what the 2 options above have already done for you after thousands of hours of testing, so arguably the stability is also an advantage of these.

I have written this sort of software before (heavy duty SFTP server code) and as long as you're confident in your multi-threading skills, this can be achieved in a relatively straight forward (but not quick) manner. It's just that testing/debugging can be a serious hindrance in this sort of scenario that Microsoft has already done for you in WS and WCF

One thing I believe we're (most if not) all agreed on is that Remoting should be put away for good, as this is a technology that MS wants to forget (and I know this first hand). perhaps Frodo can tell us why this was the technology of choice? I guess cross-platform compatibility wasn't on the agenda when the original design was done.

My £0.02 of input.

AL

 

[gljubojevic]

having looked into WCF - I am going to utilise a simple TCP based comms routine.

Essentially - send text down a TCP connection, and get a response.

Example: sending "timeshift channel bbc_one\r\n" would return either the RTSP stream name, OR "error: error messag here"

Wouldn't be easier to define interface for TVServer clients e.g. ITVServerClient and expose methods through web service.

This way clients could easily connect to TVServer and make "direct" call to method
e.g.
public ClannelList GetAvaliableChannels()
Or
public string GetChannelStream(string channel name)
....

This way you can probbaly split TVServer functionality in few Interfaces and easily extend stuff ...

Anyway what ever you do will probably be good

Question....
I'm currently working on full screen video editor for media portal...
I was thinking that when I finish this version it would be nice to split it into two plugins:
One for MP so you can edit cut points while watching video over RTSP.
Other for TVServer which will actually do cutting in background.

This way video would allways be managed by TV Server and TV Server could control list of available videos video recoding cutting etc ..

What do you think about that idea ?

Goran

 

[chrispi]

Wouldn't be easier to define interface for TVServer clients e.g. ITVServerClient and expose methods through web service.

This is definitely the right way to go. For WCF this is called a "operation contract".

There is no need to define a new protocol based on a text string. WCF is doing this in the background: It converts all parameters of a call to a XML message using SOAP format (which actualy produces a simple string containing XML)

On the client side you can create a proxy class by using a WCF tool that contains a method for each Web Service method.

You can also reference a asembly containing the interface definition on both sides (client and server). In this case you will have a stronger coupling between Client and Server. You can use complex .NET types like DataSet, Guid, ArrayList or List<> but loose compatibility. E. g. a Unix system will not be able to consume/understand a .NET DataSet-Object. When using compelex types this approach is more "Remoting" than "Web Service" like.

For best compatibility you schould only use intrinsic types like int, string or double in the interface definition. User defined complex types must be attibuted as "Data contract" and schould contain only intrinsic types to get 100% Web Service compatibility.

Regards,
Christoph