[HOME_NETWORK_TF] Re: [Fwd: local device discovery - api, demo and source code]

Thanks for the additional info, Dave.

Back to requirements for HNTF, from playing with this discovery plugin 
and our widget+UPnP experience, I get:

DISCOVERY:

Note: I believe what HNTF is concerned about is service discovery, not 
device discovery.

R1 There is a need for a high-level API abstracting the details of 
discovery, in the spirit of

scan(obj)

obj implementing

discovery(protocol, name, type, interface, address, port, devclass, description)

otherwise we will need to update the standard for every new discovery 
protocol, and it will not be possible to create generic code.
For the callback, the first parameter is the protocol, then follows a 
set of parameters whose semantics could change according to protocol, 
unless we find a unified set of parameters that works for all.
It is OK to also have a lower lever API, à la webinos.


R2 The discovery API must be designed in a way that is insensitive to a 
device / service being up or down
If a device on the home network is suddenly out of battery, it is down 
until you plug its charger, but then all the established connections 
should be back without user intervention. It is quite possible to do: we 
have such a system implemented on top of UPnP.
Otherwise it will not be usable. At least, this should be an option (on 
by default).


SERVICE COMMUNICATION:

R3 There should be a "incoming message" event and a "send message" API 
abstracting the actual syntax of the underlying service communication 
protocol.
The author should not have to deal with the details of the protocol in 
each webpage


SECURITY:

R4 There shall be a strong security mechanism that allows static 
checking and transcends script obfuscation. This could take the form of 
a manifest declaring all services and messages to be used within the 
document, with checks by the implementation that all calls or events are 
within the scope of the manifest.
You cannot be sure of what a piece of JavaScript code does, unless it is 
very simple and does not use any of the popular libraries.
So it is very difficult to judge the safety of loading a document unless 
you have this kind of security.

Best regards
JC

On 13/4/11 15:34 , Dave Raggett wrote:
> On Wed, 2011-04-13 at 15:08 +0200, Jean-Claude Dufourd wrote:
>> On 12/4/11 17:17 , Dave Raggett wrote:
>>> Forwarding at Francois's suggestion.
>>>
>>> (see also the W3C blog entry).
>> JCD: Thank you for the information. This triggers many questions.
>> - in your list of discovery technologies, why no UPnP ?
> The discovery protocol for UPnP *is* SSDP, which is covered. It uses a
> combination of a multicast search probe, unicast responses, and
> multicast notifications.
>
>> - are you saying that the discovery plugin, or web introducers, or both,
>> are relevant to this task force ?
> Both as they play different roles, see explanation in:
>
>      http://www.w3.org/2011/04/discovery.html
>
>> - how is this discovery plugin connected to Web Introducers ? I see the
>> complementarity, but not the connection.
> In principle, a third party could implement a web introducer for local
> devices on top of the local discovery API, however, it isn't clear just
> how much value this gives over a more specific wrapper library.
>
>> About the complete system using both for letting a page communicate with
>> a device:
>> - do you manage the (same) device disappearing and reappearing on the
>> network ? or is there user intervention required for each connection ?
> This is problematic as the discovery protocols are widely deployed
> (hence hard to get changed), yet don't offer the same semantics.
> Ideally, we would support an event or callback when a device is added or
> removed from the network, but that isn't going to be practical in
> general, although possible in specific contexts.
>
>> - do you have a notion of authorized device (or paired device) ?
> Yes, that happens when you want to access a device/service, and isn't
> part of the current demo.
>
>> - how does a device communicate with a page ? is there a sort of
>> postMessage from the device to the page ? or do you have a "ghost page"
>> per device to handle that ?
> There are multiple possible approaches, e.g. call backs, DOM events,
> HTTP or Web Sockets, and so forth.
>
>> Do we need the confidentiality of Web Introducers ? I do not see why.
> On local networks you can see the devices if they enable discovery, but
> it may require authentication before you can access the services they
> provide. Users should be asked for permission before an application is
> given such access, and this brings in the usual challenges of
> transparency.
>
>> With UPnP, messages are structured (not just a string). How would this
>> be dealt with in a message from a device to a page ?
> The current demo retrieves the XML device description and passes it to
> JavaScript. This is a general question of layering. Third party
> component developers will want low level access, whilst everyday web
> developers want something that insulates them from what they see as
> unnecessary details. This is where a market for third party components
> arises.
>
>> 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