W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2011

Re: Discovery and Web Intents (was Re: [DRAFT] Web Intents Task Force Charter)

From: Dave Raggett <dsr@w3.org>
Date: Sun, 13 Nov 2011 20:34:50 +0000
Message-ID: <4EC029EA.1020308@w3.org>
To: Giuseppe Pascale <giuseppep@opera.com>
CC: Dominique Hazael-Massieux <dom@w3.org>, Rich Tibbett <richt@opera.com>, Clarke Stevens <C.Stevens@cablelabs.com>, Robin Berjon <robin@berjon.com>, public-webapps Group WG <public-webapps@w3.org>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
On 12/11/11 11:42, Giuseppe Pascale wrote:
>> * The UI web page should be able to handle devices appearing and
>> disappearing at random times and be notified of such via events. Is this
>> possible?
>>
> I'm wondering if tḧis is actually needed. If you handle the "picker"
> natively, I think also this aspect will have to be handled by the browser
> and not exposed to the application.

Such events are needed for context aware applications, but this is 
probably outside the scope of an initial web intents/local discovery API 
where as you suggest, the web run-time could handle this as part of the 
picker API and  the associated background service  monitoring the 
multicast datagrams for mDNS and SSDP, and likewise for other 
interconnect technologies such as USB and Bluetooth.

> Also this is probably not part of the web intent discussion. Web intents
> provide the general infrastructure. How do we map specific services on
> intent should be handled by another spec and probably discussed in DAP 
> (or
> not?). We have 2 options here: have different intents for different
> protocols or one intent that try to cover all similar services. The first
> one is easier to implement, the second is much more handy for 
> applications
> developers. I'm starting to think that we should try to go for the second
> option. If we go for that we will have to address the problem of
> differences in capability between different (similar) services/protocols.

Agreed. We could go for a high level abstraction, but at the same time 
expose the protocol specific details for applications/libraries that 
need it. One way to do this as sub-objects for specific protocols, e.g. 
an UPnP object that provides access to the service descriptions UPnP 
defines in XML.

-- 
  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett
Received on Sunday, 13 November 2011 20:35:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:24 GMT