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
Intents.
window.navigator.startActivity seems like a solid addition to HTML5
NavigatorContentUtils.
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:
Invocation seems straightforward with startActivity. We could use
FileSaver, but
MIME does not have the added "schema URL" semantic that Intents adds.
Example:
var intent = new Intent("http://webintents.org/share";, "text/uri-list",
"http://news.bbc.co.uk";);
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:
http://www.w3.org/TR/file-writer-api/#the-filesaver-interface
Schema URLs:
Web Intents proposes a new "type" of information, an intent keyword,
essentially.
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.
Registration:
Register Content/Protocol Handler: Google has limited support for these
APIs, protocol handlers, prefixed with "web+" are rarely used.
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
http://code.google.com/p/chromium/issues/detail?id=11359
Web Intents-style is easy to understand, and seems to be more of a priority:
http://code.google.com/p/chromium/issues/detail?id=90458
http://code.google.com/apis/picker/docs/
Mozilla proposes registration in application manifest files:
https://github.com/mozilla/openwebapps/blob/master/docs/ACTIVITIES.md
Google has a registration technique for Chrome OS, for handling file
types by file extension.
It is limited to packaged, locally installed applications.
http://code.google.com/chrome/extensions/fileBrowserHandler.html
Permissions: Mozilla has expressed concerns about registerPermission
APIs, having used a synchronous variant for extensions.
http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
TL;DR:
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
registerProtocolHandler.
