Re: [HOME_NETWORK_TF] Finalizing the HNTF req doc

After more discussions with my colleagues and co-implementers, here is 
the state of our reflections.
I assume we have implemented a discovery mechanism in the HNTF or Web&TV 
user agent (named HNUA hereafter).
I assume we implement a fixed service in the HNUA called "HNUA Standard 
Service", with following messages/actions:
- listServicesAndRegisterServiceListener: message received from another 
HNUA wanting to get notified of new service and service removed
- unregisterServiceListener: other HNUA signing out
- newService: message sent to all service listeners in case of new 
service creation
- serviceRemoved: message sent to all service listeners in case of 
removal of an exposed service

Comparing this to UPnP-style service advertisement, this causes the 
sending of N messages (N = number of listeners) instead of 1 broadcast 
message.
So this is inefficient, and duplicated existing UPnP/zeroconf functionality.
I do not like it, but I have to admit that I could probably live with it.

However, I want to insist that we have really TWO gaps, service 
discovery and service advertising.
What you propose is a supposedly easier to implement solution to the 
secnd gap.
It does not remove the existence of the service advertisement gap.

So I would insist that we describe two gaps in the document, even if I 
would agree to also include a sentence saying that the service 
advertising gap may be filled by something else than UPnP/zeroconf 
service advertisement techniques.
Best regards
JC

On 30/9/11 12:06 , Giuseppe Pascale wrote:
> 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
>
> /g
>
>
>> Thanks
>> JC
>>
>
>


-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144

Received on Friday, 30 September 2011 16:35:29 UTC