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

On Sun, 13 Nov 2011 21:34:50 +0100, Dave Raggett <dsr@w3.org> wrote:

> 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.
>
Note also that the "service not available" problem is common also to could  
based services.
I'm not sure what's the current plan for intents, but my understanding is  
that the issue of a service not responding is handled a communication time  
and not a selection time.
Am I correct?

>> 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.
>
yep. This needs more thoughts and more discussion though. Exposing more  
information will also bring back the security and privacy concerns someone  
raised. So we need to discuss if there is a way to handled features that  
are specific for one protocol/service preserving privacy/security as much  
as possible. I guess we need to give it a try and discuss around some  
draft/prototype.

/g

-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Monday, 14 November 2011 09:34:26 UTC