Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter

On 11/10/11 3:10 PM, Greg Billock wrote:
>
>
> On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett <richt@opera.com 
> <mailto: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.

Has there been further movement toward the existing register*Handler APIs:
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers

I've practiced with those methods and from a usability perspective, I'm 
starting to think those html5 methods are not going to be worth using.
Whatever the end-case, Web Intents seems to be where the UI is going to 
evolve.

I understand that from the Chromium-OS side, Web Intents is likely to 
take over the fileHandlers permission.
That tells me that registerContentHandler is not going to happen.

Chromium-OS is headed from a vendor-specific extension into web intents:
http://code.google.com/chrome/extensions/fileBrowserHandler.html

I'm OK with that. I want to make sure we're all aware of the divergence.



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


It seems like the anchor download attribute fills another need. Should 
these proposals be wrapped up into an omnibus package?
In my opinion, they're an extension to the very-old "target" attribute.

In the new Web Apps world, we're targeting FileSaver and iframe sandbox.

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

Hixie made a good point when he asked us to review Web Messaging. 
Intents as it's implemented by Google -- and it's already happening -- 
Google started this push awhile ago and I get the impression that Paul 
Kinlan has high level support -- intents as it's implemented is built 
upon Web Messaging and postMessage dynamics.

postMessage has MessagePort and Transferable arrays (thank goodness). I 
believe those semantics already solve issues of RPC, bi-di and 
zero-copy. They've had years of work put into them to get to this place 
of consensus.

timeless brought up some excellent corner cases that I hope are 
discussed soon in the upcoming TF mailing list. That stated, I think 
building Intents atop postMessage is the right move. Web Messaging has 
already solved many of the difficult problems.

As far as I can tell, Web Intents adds another high level semantic: the 
"Intent" semantic. I've proposed previously that intents could work over 
HTTP in addition to the browser and OS interoperability, simply by 
adding a "Web-Intent(s):" header onto Web Sockets and HTTP RPC requests.

A Web-Intent may have a mime-type, it'll have some kind of message body, 
perhaps some arguments -- the one thing it adds onto existing semantics 
is yet-another text field describing the intent. That extra dimension of 
information seems sufficient to handle many use cases -- yet to be 
discussed on the Web Intents TF list.

-Charles