Web Intents: Proposed modifications to the spec regarding registration

This is the first of a couple of posts suggesting modifications based
on the thinking Ian Hickson has done on remaining issues with web
intents [1].

Currently the draft spec proposes a declarative registration
mechanism. I think there's wide agreement on the merits of that
approach, but it's difficult to devise a good way to open it up to web
pages at large in an experimental way that will enable us to learn
from the resulting usage. An imperative API is easier to experiment
with.

In addition, adopting as Ian does the design goal of consolidating
services handling custom protocols, content types, and web intents
invocations is really attractive. It points to solutions to a lot of
open questions about declarative invocation, url filtering, and
content-based invocation that are really exciting for the platform. A
consequence, though, is that we'd end up needing an imperative
registration API anyway to provide symmetry with
registerProtocolHandler and registerContentHandler.

So in light of this, does anyone have any objections to adding an
imperative registration API to the spec? Ian's proposal in [1] is:

registerIntentHandler()
unregisterIntentHandler()
isIntentHandlerRegistered()

I'm still very uneasy with registration snooping of any sort, but if
same-origin policy is applied it becomes less of an issue (though
hardly one that can be ignored).

Any overall reactions to this plan?

Here is a specific proposal:

registerIntentHandler(IntentServiceDescriptor);
unregisterIntentHandler(IntentServiceDescriptor);

The IntentServiceDescriptor is an object literal (in symmetry with the
invocation API), and with the same fields as the proposed tag
attribute:

dictionary IntentServiceDescriptor {
  DOMString action;
  DOMString type;
  URL href;
  DOMString title;
  DOMString disposition;
}

This differs from Ian's proposal in laying out the arguments as an
object literal rather than ordered parameters. This has the
disadvantage of asymmetry with registerProtocolHandler and
registerContentHandler. It has the advantage of being very flexible
going forwards, as well as symmetry with the proposed invocation API.


[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/036719.html

Received on Wednesday, 15 August 2012 23:50:18 UTC