Re: DAP rechartering discussion

On Mar 21, 2011, at 7:02 AM, Robin Berjon wrote:

> On Mar 16, 2011, at 05:32 , Mark Watson wrote:
>> My main comment is that I would not expect standardization to reach so high in the stack. Or at least we should decouple the discovery, connectivity and security aspects (which are generically useful) from aspects such as content search and metadata, which IMO are service-specific (or source-specific in your terminology).
> 
> One thing that I like a lot about the way in which UC is currently specified is that one can easily split various bits off. There could be a UC Core specification with everything that's absolutely required, and then the other parts could be independent components. Since they're already optional and have a discovery mechanism, it should be relatively easy.
> 
> In my experience from writing EPG apps though, I have to say that having some baseline search and metadata interoperability would be very, very nice. This doesn't have to be all-powerful (that's too hard a problem to solve) but at least some minimally common parts (navigating categories, simple full text search) helps a lot.

In the interest of provoking debate, I'd say that I'm not sure the concept of a universal "EPG" is valid in the "web&tv" world at all. There is no "Electronic Web Guide" for the web. We have search engines, but these are 'as thin as possible' to get you as fast as possible to the site you want: they do not constrain sites to be described in some particular metadata format, but there are tools for sites to describe themselves to search engines if they wish. If you know what site you want, you go can straight to that and, either way, the site then has control of your user experience when you get there.

I think we should be enabling similar models for TV services and for multi-device services as well. 

> 
>> For example, I would find it very difficult to see how a service such as Netflix's could fit into the model you've defined: we have our own metadata, including categories, and would expect to have our own User Interface on both the TV and the remote: they need to discover each other and communicate but after that their communication probably needs to be proprietary, since standards cannot anticipate the ways we will want to innovate with respect to the Remote<->TV interaction and their respective user interfaces (and nor can I).
> 
> Not standardising everything and boiling the ocean is definitely a feature. One question to you here though: there's a difference between proprietary and closed. With UC as currently specified, you could add your own extension service on the server, and clients could use it. It would be proprietary, but not closed (third party developers could address it). Would third parties enhancing your service (e.g. writing clients that they think is better than the stock one you could ship) be seen as a problem from your end?

REST designs certainly enable great flexibility in terms of componentization, especially in the sense in which clients are unaware of functional distribution on the server side.

The last question is a business one. My answer to those things is always that the technology should enable things that the business might want to do.

One can imagine the "discovery and security" layers of a UC API being baked into the device, but once you've discovered a service you get a link to a resource which is hosted by that service itself - i.e. service-specific web app code on the device, enabling direct interaction between service specific client and server rather than having that interaction mediated by a standards-defined layer baked into the device.

...Mark

> 
> -- 
> Robin Berjon - http://berjon.com/
> 
> 
> 
>

Received on Monday, 21 March 2011 19:25:18 UTC