W3C home > Mailing lists > Public > public-web-intents@w3.org > August 2012

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

From: James Hawkins <jhawkins@google.com>
Date: Tue, 28 Aug 2012 09:19:58 -0700
Message-ID: <CAO800SwXKsgoYzmHX6i5qz+Nwy_U5mOongQvCOmGyr5g_d-Y3w@mail.gmail.com>
To: Greg Billock <gbillock@google.com>
Cc: WebIntents <public-web-intents@w3.org>, Ian Hickson <ian@hixie.ch>
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

> 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 Tuesday, 28 August 2012 16:21:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:47 UTC