W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Deconstructing Intents was, Re: Adding Web Intents to the Webapps WG deliverables

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 22 Sep 2011 09:24:02 -0700
Message-ID: <4E7B6122.9070101@jumis.com>
To: Marcos Caceres <w3c@marcosc.com>
CC: ifette@google.com, Robin Berjon <robin@berjon.com>, James Hawkins <jhawkins@google.com>, public-webapps@w3.org
On 9/20/2011 10:27 AM, Marcos Caceres wrote:
> On Tuesday, September 20, 2011 at 7:17 PM, Ian Fette (イアンフェッティ) wrote:
>> While issuing a ton of patent exclusions for something like this would be rather poor, I would frankly rather have that then a spec that doesn't get any attention from a party that's clearly relevant only to have patents come up /after/ the spec is published and implemented.
>   Agreed, but for that we need to go through rechartering this group to include the new deliverable (i.e., to give everyone a fair chance to say if they are willing to give up their IPR around this). I think your concerns are fair.

While all that gets worked out, it'd be great to have active 
participation on public-webapps from Microsoft and occasional input from 
the HTML5 Editor and assistant.

I'd like to see navigator.registerContentHandler integrated into Web 
window.navigator.startActivity seems like a solid addition to HTML5 
There is some overlap with File API FileSaver.

I understand that Web Intents has been in development for some time: I'd 
like to deconstruct and reconstruct the components to get a clear idea 
of side effects.

Web Intents proposes three items: registration, invocation and schema URLs.


Invocation seems straightforward with startActivity. We could use 
FileSaver, but
MIME does not have the added "schema URL" semantic that Intents adds.

var intent = new Intent("http://webintents.org/share", "text/uri-list", 
var saver =  new FileSaver(blob, "filename.ext");

FileSaver requires blob encapsulation.
Blob encapsulation is a bit of extra-work when working with array 
buffers, and strings, and the like.

FileSaver Progress events are handy:

Schema URLs:

Web Intents proposes a new "type" of information, an intent keyword, 
There are a handful of common intents defined in the proposal, all of 
them prefixed with "http://webintents.org/".

I'd like to see that prefix stripped. Given that Web Intents -is- 
defining the standard, I do not see a good reason for the extra baggage.
I'd prefer  keyword | uri as option, instead of just URI.

Thus:  var intent = new Intent('share', 'text/uri-list', 
'http://w3c.org');  // Much shorter.

Intents does seem to be something that can work for RPC, in addition to 
current HTTP headers.
I could easily see this working across web sockets as well as it works 
through intra-browser postMessage.

A "Web-Intent" HTTP header might prove valuable.
A URL might register itself to accept POST and Web Sockets submissions.

Consider a header of:
Web-Intent: share

A supporting server could then process that data server-side.


Register Content/Protocol Handler: Google has limited support for these 
APIs, protocol handlers, prefixed with "web+" are rarely used.

Web Intents-style is easy to understand, and seems to be more of a priority:

Mozilla proposes registration in application manifest files:

Google has a registration technique for Chrome OS, for handling file 
types by file extension.
It is limited to packaged, locally installed applications.

Permissions: Mozilla has expressed concerns about registerPermission 
APIs, having used a synchronous variant for extensions.


FileSaver and Intent have very similar use cases -- it's quite 
reasonable that a FileSaver would run an Intent session on the UA, 
allowing a user to "save" their file to various registered targets. Look 
for harmony.

Intent schema URLs seem fine, but there's no reason to have 
"http://webintents.org/" as a standard prefix, strip the prefix there. 
Consider HTTP 1.0/Web Sockets support, as an addition to the scope.

Registration is tricky. Manifest files seem like a solid place to start. 
registerHandler seems like a good addition to registerContentHandler and 
Received on Thursday, 22 September 2011 16:24:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:24 UTC