Use WebService between Server and Client (1 Viewer)

[drfonz]

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.

Christoph is right in the compatibility front. And again, remembering the whole point of this exercise is to be able to have non-Windows (or at least non .Net-enabled) devices as clients we can't rely on .Net complex types.

My WS version abstracts all this and serialises all the complex results into standardised XML structures which can be bound to schemas so that any potential clients can basically receive the WS response and then parse the resulting XML construct easily.

Things like GetChannelList(), AddSchedule() and DeleteRecording() become then a very simple WS interface with which to work.

Also, gljubojevic's suggestion of an TVServer client interface is most definitely the way to go as far as the server is concerned, although from the point of view of the client this is transparent, as the WS client will not deal in interfaces but in contracts using UDDI, WSDL and other associated technologies...

AL

 

[richbayliss]

This is getting complex really fast.

What I suggest is that we start a pluggin going for the TVserver which has a library CS file containing stubs for all the actions we need. In these stubs, put the actual code to make the TVengine @do@ something (record etc)

Once we have the functionality within the plugin, lets look at exposing this through WCF.

Shall I propose a set of methods we wish to expose, and start the coding? How can I get this into a publicly accessible SVN location?

 

[drfonz]

I think this thread should be moved to the Development forum.

Any mods listening?

 

[and-81]

Shall I propose a set of methods we wish to expose, and start the coding? How can I get this into a publicly accessible SVN location?

https://forum.team-mediaportal.com/plugin_development_svn-t15863.html

 

[nhdezoito]

Started on: 2007-01-25
last update: 2007-01-25

Summary:
Instead of using a direct connection to the SQL server for information (EPG etc), why not use a series of remote methods (WebService) to access the functionality.

Description:
By using a webservice to comunicate, there doesnt have to be any configuration of SQL Server. Also, the TVengine can be updated functionality-wise - without requiring a newer TVclient plugin (assuming the same WS methods are intact)

Examples:

1) Start Timeshifting
-- StartTimeshift(Channel); returns stream details

2) Schedule a Recording
-- RecordChannel(Channel,StartTime,EndTime) returns true/false depending on a clash etc

3) Getting the EPG
-- GetEPG() returns a DataSet/XML data etc

Obviously this adds the requirement of IIS to the TVserver - but since we have SQL Server anyway, I don't see this as an issue.

What is the status of this plugin development?

 

[nhdezoito]

Started on: 2007-01-25
last update: 2007-01-25

Summary:
Instead of using a direct connection to the SQL server for information (EPG etc), why not use a series of remote methods (WebService) to access the functionality.

Hi all
There is a way to access the SQL information from the TVEngine3 remotely?

 

[dvdfreak]

I'd just like to jump in here to put up my vote for using WCF (or Web Services if Framework 3.0 is not being considered) for client/server communication. If people have been reading the fuzzy recording thread they may have noticed there was a testing problem there because some DLL's on the client weren't updated, when they WERE updated on the server. This gave weird results (obviously).

Such a situation would not have occured of the database access was behind a service. Then the client would have automatically picked up the new behaviour of the server.

The real challenge would be to get the service API right, simple enough, and as stable as possible. Because if the service contract changes then the client DOES have to be updated.