[whatwg] Proposal: <intent> tag for Web Intents API

[James Hawkins]

On Thu, Dec 8, 2011 at 12:43 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 6 Dec 2011, James Hawkins wrote:
>>
>> One of the critical pieces of the API is a declarative registration
>> which allows sites to declare which intents they may be registered for.
>> The current draft of the API calls for a new HTML tag, <intent>, the
>> attributes of which describe the service registration: [...]
>
> Separate from the issue of what precisely the element should look like, I
> wonder if you could expand on the precise use case for the element. In
> particular, I'm interested in whether this use case might also apply to
> some of the register*Handler() methods we have now.
>
> Ideally, it would be good to have the current protocol and content type
> handlers and the Web Intent stuff all use a coherent and consistent API.
>

Absolutely, we're very keen on providing RPH/RCH functionality via Web
Intents.  Let me start with the use case for the intent element, then
I'll get to R*H.

*** Use cases ***

The intent element serves as a declaration of functionality of a web
app.  For example, Twitter exposes share functionality, Picnik exposes
editing functionality, Dropbox exposes pick/save functionality, etc.

Once the user accepts these registrations (gives permission), the UA
can connect a client requesting a given set of functionality to the
service that previously exposed that functionality.

The fact that the element is declarative is a win wrt sites that may
wish to crawl the web to index which web app handles which
functionality.  See www.openintents.org/en/intentstable for an example
of this for Android Intents.

*** RPH/RCH ***

registerProtocolHandler gives services a way to imperatively expose
functionality that is to specific to protocols.  Web Intents will
handle this use case by adding a scheme/URL pattern attribute to the
intent registration.  Android Intents exposes scheme/URL pattern
filtering as well, so this addition moves Web Intents that much closer
to its model API.

navigator.registerProtocolHandler("mailto",
"https://www.example.com/?uri=%s", "Mail Service");

becomes

<intent scheme="mailto" title="Mail Service">
 Click here to install our Mail Service application!
</intent>

registerContentHandler allows services to imperatively expose
functionality that is specific to content types.  Web Intents will
provide this use case by special-casing the intent element when no
action is provided for a particular MIME type.

navigator.registerContentHandler("image/png",
"http://www.example.com/?foo=%s", "My Image Viewer");

becomes

<intent type="image/png" title="My Image Viewer">
 Click here to install our Image Viewer application!
</intent>

Of course the fallback content is optional and determined by the
service, but we believe it's a great way to expose fallback
functionality via installable extensions/apps/whatnot.

*** Advantages ***

Client-side handling.  For R*H, ?foo=%s normally requires server side
processing.  With Web Intents, this data is passed completely
client-side on the intent object.

Wildcard matching.  R*H does not allow wildcard matching, where as Web
Intents would allow a service to register for image/* in one succinct
registration.

Thanks,
James