Re: Web Intents: Proposed modifications to the spec regarding registration

Question in-line:

On Wed, Aug 15, 2012 at 4:49 PM, Greg Billock <gbillock@google.com> wrote:

> 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).
>
>
Can you elucidate what you mean by applying same-origin policy to
isIntentHandlerRegistered()?


> 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
>
>