Re: [DRAFT] Web Intents Task Force Charter

On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett <richt@opera.com> wrote:

> Dominique Hazael-Massieux 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.
>>
>
Yes. The API as currently proposed has a way for web apps to register
services, but it is not intended to limit the ability of the user agent to
register services by other methods. If you look at our Chromium commits,
we're experimenting with ways to register services through installation of
web apps, for instance. Registering handlers through local network
discovery or interaction with the host OS also seems like a promising
direction.



> 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.
>>
>
> This is unclear but I hope we end up with something that provides
> non-tabbed (direct) interaction also. In some cases it may be superfluous
> to have a separate window open that denotes the service endpoint.



The proposal we're working from uses "disposition=inline" to denote this --
that is, services can be placed within the visual context of the calling
page. Our prototype uses an expansion of the service picker dialog to host
that service page.


> Thanks for the quick reply and good to ensure this stuff gets captured in
> the TF charter.
>
> As Chaals said, let's get going on this. The concept of Web Intents is
> great and we're not married to any particular proposal at this point. We
> can see if it works for our UCs when the task force kicks off.
>
>

Clarke Stevens asked about a discovery mechanism whereby a client page
discovers a set of local network devices which is then updated by an event
driven mechanism. As currently sketched out, there's room in our web
intents proposal for the return of a MessagePort for persistent
communication. The proposal doesn't focus on that problem, though. It is
aimed more at an RPC-style request/response interaction paradigm. Web
Intents, the way we're currently thinking about it, has a lot to do with
user consent to the connection between the applications. When there's a
persistent connection, that consent model starts to break down. That said,
there are definitely use cases for which establishing a persistent
connection is appropriate. I'm eager to discuss how to best handle those
cases as the TF starts up. I think that'll be a key focus of refinement.