[whatwg] register*Handler and Web Intents

[Greg Billock]

On Wed, Jul 25, 2012 at 7:20 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>> Our remaining discomfort here is with isIntentHandlerRegistered(), and
>> for similar reasons to the fingerprinting qualities of
>> isProtocolHandlerRegistered(). That is, we'd prefer that web content
>> simply call registerProtocolHandler blindly, similar to what a
>> declarative registration would do, and let the UA sort out whether the
>> user ought to be shown any kind of registration UI.
>
> These is*Registered() methods don't expose anything that isn't already
> possible with cookies, so I propose that we just disable them if cookies
> are disabled, and say that clearing cookies should recommend clearing the
> registrations too.

I don't like the fingerprinting potential here, and would prefer
getting rid of all the is*Registered methods. Thinking about it as an
analog to the declarative scheme, the page is basically telling the
browser "hey, I'm a service" to which the browser can respond in many
ways (ignore it, check existing registrations, write it down to be
considered later, pop up an infobar, show a dialog if the call is
accompanied by a user gesture, etc.)

>
>
>> At the DAP meeting, we agreed to extend this system to include
>> string-literal types, which provides a way to do good integration with
>> microdata types. There we expect to do exact string matching, and it is
>> true the eliminating wildcard types would bring these two type
>> namespaces a bit closer. MIME is complex enough that it would still have
>> to be treated separately, however. (Parameters and all that.)
>
> I'm not really sure I follow here. Could you elaborate?

For microdata types, the matching would be exact. For MIME types, you
need MIME-specific matching, since a service registered for
"text/html;a=b&c=d" should be delivered a payload with
type="text/html;c=d&a=b".

In public-web-intents, we anticipate important schema definitions
which are independent of the API (such as this one) to end up in
either best practices docs or additional addendum documents that
describe how to use MIME types, or various microdata types, or
interchange types made for other specs.


> On Thu, 24 May 2012, Greg Billock wrote:
>>
>> 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.
>
> Do we need to support a space-separated list at all? When will the list be
> so long that it really makes sense to add that feature rather than just
> having three registrations back-to-back?
>
>
> (I have omittd a number of e-mails from this reply that gave suggestions
> that seemed reasonable and that have therefore been incorporated into the
> proposal above.)
>
>
> If nobody finds any egregious problems with the proposal above, I'll start
> speccing it as part of a rewrite of the register*Handler() section. (That
> section needs a rewrite into more imperative language anyway.)

I'm not sure how to assess the options of using <link> or <meta> in
place of <intent>. It looks to me like competing intuitions about the
relative benefits and hazards of having something specific but new to
the parser versus more overloading of existing generic terms.

Would it make sense to consider this in the context of other
declarative invocation possibilities? That is, if there are ways to
invoke the feature without navigator.startActivity() or
window.startIntent(), does that change the intuition about having a
specific <intent> tag? As Ian has described, we can invoke these
handlers with <a href="protocol://x"> with the RPH form, and with any
link with the RCH form. Analogous imperative calls can be done in
Javascript which would cause the same dispatch pathway to be executed.

But there is an option to explore more interesting navigational and
declarative interactions that have come up in discussions with Alex
Russell and other folks about this feature. For instance, you can
imagine a generalization of these navigational forms that allow a
registered handler to intercept navigations to a particular
same-origin url space  (i.e. "http://example.com/app/*" or
http://example.com/app/page?*"). This would enable app authors to have
a high degree of control over their site's caching behavior while
off-line, potentially helping with the functionality of appcache-style
behavior. There are a couple of other related use cases, for example,
having an existing open application or document be able to intercept
self-navigations to re-activate itself.