Re: [HOME_NETWORK_TF] Finalizing the HNTF req doc

On Fri, 30 Sep 2011 18:35:05 +0200, Jean-Claude Dufourd  
<jean-claude.dufourd@telecom-paristech.fr> wrote:

> 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.
>
I'm not sure your concern is valid for advertisement. If your  
application/service you another service (HNAdsService) to advertise  
himself on the network, you will always talk only with that service, that  
in turn will be able to generate multicast notifications. So this would be  
equivalent to UPnP.

I think we should avoid to equate the term Service to a "UPnP service".  
Here service (IMO) is more genericaly a functionality provided by a device  
(that could be the UA itself)


> 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.

When I talk about gap here, I'm not talking about requirement anymore but  
technical gaps. It seems to me that once we have some technical means to  
do discovery, every other requirement may be implemented on top of it (if  
properly designed).

Note also that I'm not necessarely saying this is the most effective way  
to do so, just saying that without implementing it is difficult to say if  
will be enough.

>
> 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.

I'll make an attempt to capture what discussed and circulate some text for  
inclusion into the requirement document later today or tomorrow.
So you can provide me with some feedbacks.

cheers,
/g

> 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
>>>
>>
>>
>
>


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Monday, 3 October 2011 09:27:37 UTC