W3C home > Mailing lists > Public > public-web-and-tv@w3.org > September 2011

Re: [HOME_NETWORK_TF] Finalizing the HNTF req doc

From: Giuseppe Pascale <giuseppep@opera.com>
Date: Fri, 30 Sep 2011 12:06:50 +0200
To: public-web-and-tv@w3.org, "Jean-Claude Dufourd" <jean-claude.dufourd@telecom-paristech.fr>
Message-ID: <op.v2l81ohn6ugkrk@giuseppep-x220>
On Fri, 30 Sep 2011 09:34:37 +0200, Jean-Claude Dufourd
<jean-claude.dufourd@telecom-paristech.fr> wrote:

> On 29/9/11 14:04 , Giuseppe Pascale wrote:
>> ** Actually, I've been considering going down to ONE gap: discovery.  
>> Once you have discovery, you may implement advertisement as a service  
>> (at least to start with). What do people think?
> I cannot find how that could be correct. Any way I look at it,  
> advertising new services through a fixed service does not solve the  
> problem.
> Would you please describe your solution in detail ? Maybe I just missed  
> something.
You have more options:

1. If we define the concept of "service" in a very generic way as a  
functionality, on service could be advertisement. The functionality itself  
could be provided by the UA but exposed as a service. Of course there is a  
need to standardize the language to use to talk to such service,but could  
be simple JSON commands (at least in a first stage)

2. You could discover and "advertising service" (a register) and then  
subscribe to it. Another app that want to discover you can discover such  
register and
interrogate it to "discover" you. There are different way to deploy this,  
the advantage is that it does not require any additional API.

This approach is also used in other contexts, for example with Web  
Services [1] and UDDI registers[2]

[1] http://en.wikipedia.org/wiki/Web_service
[2] http://en.wikipedia.org/wiki/UDDI


> Thanks
> JC

Giuseppe Pascale
TV & Connected Devices
Opera Software
Received on Friday, 30 September 2011 10:07:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:04 UTC