Re: [DRAFT] Web Intents Task Force Charter

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?

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

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

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

* 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)?

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

Received on Thursday, 10 November 2011 16:22:01 UTC