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

until we don't have a ML....quick comments.
I would ask people more familiar with intents to correct me if I'm wrong

On Thu, 10 Nov 2011 17:20:46 +0100, Clarke Stevens
<C.Stevens@cablelabs.com> wrote:

> Dominique,
>
> Your example below is very helpful. I have a couple of follow-up  
> questions:
>
> * I want a single web page with the UI exposed to the user. The user
> should not see any additional tabs or browser windows (except perhaps a
> pop-up child dialog listing available relevant services). Is this  
> possible?
>
IIUC all the examples with windows and tabs are just examples. How the
choice is presented to the user is an implementation details and this
allow the browser manufacturer to customize the view based on your needs
(e.g. browser embedded in TVs often to not have tabs or not even a chrome)

> * The UI web page should not have any information about what devices are
> discovered in the local network until given explicit permission by the
> user. This would prevent most snooping scenarios. Is this possible?
>
I think that if we want to go "the intent way" the idea is that the web
page NEVER have information about the devices.
I think is good to preserve privacy here. Before exposing this to an
application we need to make sure is actually needed.

> * 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.
The only thing that needs to be handled is when you are not able to
communicate with a service, but that would be equivalent to a web based
intent not being available (e.g. becuase network is down or the web server
is down or whatever)

> * The devices and services discovered should be determined by very
> specific service types within existing protocols (e.g. An AV rendering
> device as opposed to a content server). Is this possible?
>
I think this is covered by intents.

> * Could multiple protocols be supported for the same service (e.g. A
> Zeroconf DAAP server and an UPnP CDS as sources for the same directory
> tree window on a UI web page)?
>
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.


/g

> Obviously, we'll need to go into all of these questions and more in  
> detail
> as we explore this, but I just wanted to get some high-level feedback on
> some cases that may not be good fits for the Web Intents usage model.
>
> Thanks,
> -Clarke
>
> On 11/10/11 8:58 AM, "Dominique Hazael-Massieux" <dom@w3.org> wrote:
>
>> Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit :
>>> Hi
>>> a.) to register a URL endpoint as an intent provider the user must
>>> visit
>>> a web page (presumably hosted by the target device itself) and capture
>>> the intent registration from that page before that intent provider can
>>> be used within the UA.
>>
>> My understanding is that this is not a MUST at all, but the way
>> Web-based services can be added by a user.
>>
>> For a local network approach, my take would be that the browser would be
>> doing the discovery, and possibly offer the user to add local services
>> to the list of available providers when such a service matches the
>> requested intent.
>>
>> Typically, a "gallery" intent (i.e. requesting a list of medial files)
>> would make the browser list local media galleries (from UPnP) in
>> addition to the registered Web services (e.g. your on-line photo
>> albums).
>>
>>> b.) to then subsequently use a registered intent provider the concept
>>> is
>>> to open that provider, again as a web page in a seperate tab within the
>>> UA. From here we can then establish a bi-directional web messaging
>>> channel on which we can send and receive messages to communicate to and
>>> from that web page that is representing the current local service.
>>
>> I think the Web-page-in-a-separate tab is also an optional aspect of Web
>> intents; the browser could serve as a broker between the local-network
>> service and the Web page.
>>
>>> Perhaps someone could take the time to describe exactly how a user
>>> could
>>> communicate with an existing TV device in their home from a web browser
>>> supporting web intents based on the above requirements?
>>
>> Here is a rough sketch:
>> * user hits a Web page that wants to load a picture from his gallery
>> * that Web page asks for an intent for media gallery
>> * the browser shows to the user the list of services that can provide
>> media galleries; having detected that there are such services on the
>> local network, it includes these services in the list
>> * the user wants to pick a picture from the gallery hosted on his TV, so
>> picks the TV set in the list of services
>> * from then on, the browser turns the messages sent by the Web page via
>> postMessage() into UPnP requests that the TV set can respond to, and
>> also turns the responses into messages that the Web page can deal with.
>>
>> Dom
>>
>>
>>
>


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Saturday, 12 November 2011 11:43:27 UTC