Re: [whatwg] register*Handler and Web Intents

On Fri, Apr 20, 2012 at 10:35 AM, Greg Billock <gbillock@google.com> wrote:
> Ian,
>
>
>> My suggestion then would be to add an element similar to what you suggest,
>> as well as an API similar to the existing one.
>>
>> The element could be something like:
>>
>>   <intent
>>     action="edit"     intent action, e.g. open or edit, default "share"
>>     type="image/png"  MIME type filter [1], default "*/*"
>>     scheme="mailto"   Scheme filter [1] [2], default omitted
>>     href=""           Handler URL [2], default ""
>>     title="Foo"       Handler user-visible name, required attribute
>>     disposition=""    "replace", "new", or "overlay", default "overlay"
>>   ></intent>
>>
>> [1] Only one of type="" and scheme="" is allowed.
>> [2] scheme="" is only allowed if href="" contains %s.
>>
>> The API could be something like:
>>
>>  void registerIntentHandler(DOMString action, DOMString type, DOMString url, DOMString title, DOMString disposition);
>>  DOMString isIntentHandlerRegistered(DOMString action, DOMString type, DOMString url);
>>  void unregisterIntentHandler(DOMString action, DOMString type, DOMString url);
>>
>> The disposition of registerContentHandler() and registerProtocolHandler()
>> would always be "replace". The /url/ argument of registerProtocolHandler()
>> would not be allowed to contain %s.

Here's a slightly altered suggestion. There'd be three imperative
registration APIs and three permissible intent tag configurations:

For web intents services:
<intent action=a type=t href=u ...>
(that is, both action and type required, scheme disallowed)
void registerIntentHandler(a, t, u, ...); // and unregister

for protocol handler services:
<intent scheme=s href=u ...>
(scheme required, action and type disallowed)
void registerProtocolHandler(s, u, ...); // and unregister

for content handler services:
<intent type=t href=u ...>
(type required, action and scheme disallowed)
void registerContentHandler(t, u, ...); // and unregister

intent tags without these permissible permutations of
scheme|action|type attributes must be ignored.

Some more concordance moves to make them more like different aspects
of the same feature:

* In registerContentHandler, "t" can be a space-separated list of MIME
types for registerContentHandler.

* Let's think through why we'd need to limit the dispositions of the
case of RPH/RCH to disposition="replace". Can't we achieve backwards
compatibility by specifying that those cases default to
disposition=replace? This would make it straightforward to get a nice
style of navigational interaction with web intents -- RPH-style
invocations can be handled by any of the disposition transitions.
(i.e. a "mailto" handler that did all it's work in an overlay, which
is frequently very desirable).

* Add a couple more legal permutations: adding 'action="view"' to the
RPH/RCH registration intent tags would mean that the payload gets
delivered using web intents instead of through %s-substitution. The
RPH/RCH APIs wouldn't expose this. (This is very useful for offline.)

These aren't large modifications, and in general just increase
"forward compatibility" by making it more clear how to get more
functionality out of RPH/RCH by using declarative registration, and
blending those cases into the intents-based implementation.

-Greg

Received on Thursday, 24 May 2012 22:56:30 UTC