Re: A simpler, webbier approach to Web Intents?

On Thu, Feb 16, 2012 at 2:15 PM, John J Barton
<johnjbarton@johnjbarton.com> wrote:
>> We explicitly support passing any structured-cloneable type in intents
>> payload. This includes Blobs and other file-ish types, ports, and
>> esoterica not yet invented. :-)
>
> Then how do you have an advantage over postMessage() over MessageChannel?

I was just clarifying that we do not intend to allow passing of a
narrower range of types than would be possible with postMessage in
page-to-page situations.

There are many situations, though, where it is preferable to pass MIME
types, allowing the user to use a wider range of tools to handle the
intent. Imagine invoking a local image editor, for instance, or being
able to invoke a web site with a button on your photo download
software to share a photo.

>
> The part that is missing is how a user who wants to complete a task
> finds the web page with the corresponding <intent> tag so the service
> can be registered.
>
> Based on your description it sounds like web-intent services have some
> of the properties of bookmarks (remembered pages) and cookies (the
> page isn't explicitly what the user is saving). Is that correct?
>
> So you are counting on users to go around building up a list of useful
> services before they need them?


Ah, I see. Yes, that is a major issue. It is hard to address it
directly in the spec, since it isn't strictly a technological problem,
and also because we think that a lot of the task of solving it is best
left up to the user agent. We've definitely thought about it, and it
is a common concern of publishers. There's a couple features of the
draft that directly address this.

First, using a declarative registration syntax makes developing a
registry of services a lot easier. I'm familiar with the operations of
one search engine which is capable of creating such an index, but
making that process accessible is a design goal that went into
motivating declarative registration. Additionally, leaving this
process up to the browser means that registration can be quite
light-weight, meaning users are more likely to have surfed by services
they'll use by the time they want to use them to complete an intent.

Second, we plan on exposing registered apps in the Chrome Web Store
which provide intents functionality as a way to solve this discovery
problem. We think that since all the data is kept locally, we can do a
good job of combining server-side search for qualifying services with
the user's bookmarks in a way to have a really good chance of
surfacing good suggestions for the user.

Third, we are contemplating a change to the draft to include the
ability for publishers/clients to include suggested services to the
picker. This is included in James Hawkins' most recent mail to WhatWG.
[1]

To the question about cookies, our prototype registry basically has
fields for the elements of the intent registration operation: we write
down the url of the service, the action/type it is interested in. We
also write these down for installed extensions/apps, as well. So
you're right, they are a lot like a bookmark (more like a bookmark
than a cookie, as there is no intrinsically user-identifiable
information included in the record, although it is definitely a
privacy concern because of super-cookie potential of the registry, but
that's another story).

Just to complete the story, when a user triggers an intent on a client
page, we match the action/type of the intent against services stored
in the registry, pick the qualifying services, and present the list to
the user, who can then select one with which to complete the action.
You can try this out in the current Chrome beta and developer channel,
if you're interested in seeing how we think this will work.

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-February/034881.html

Received on Friday, 17 February 2012 01:57:07 UTC