Re: rewrite of section 4

Thanks, Jean-Claude,

The image I get here for web content is that the user should be
allowed to expose the intent registrations to the page, and let it
perform the picker functionality. Is that right? Are you suggesting
this be installable in general? Or just for intents invoked in that
app?

That is, would the following API allow you to satisfy the use case you
have in mind?

IntentRegistration[] retrieveIntentHandlers();

Then, coupled with explicit intents, the page could directly dispatch
intents to services as it desired.

In addition to this, the browser could expose such an API as part of
its extension mechanism to let other local code extend the picker (and
presumably, to gain access to the list of registered handlers). I
agree that the spec shouldn't mandate particulars of that extension
mechanism.

The big shift is that currently, although it is not explicitly called
out in the spec, my assumption has been that the UA maintains
confidentiality of registered services. This contract allows services
to attach tokens to those urls, which aren't disclosed to any other
app. If we expose the urls, it means the ability of services to count
on their confidentiality will disappear. Perhaps that's not too much
of a sacrifice, however.

I think a larger concern is that exposing this API is enough of a
privacy concern that it means we'd need to treat registered service
urls differently. Installing an extension carries a much higher trust
relationship than what users would expect from allowing a permission
on a web page, it seems to me, and there are a lot of privacy
implications in exposing persistent registered data like this.

I'd like to see if we can solve these problems, however. Exposing this
capability to web content is useful in several ways. It is a good
approach to a set of use cases that web intents currently aren't that
great for -- actions where there is a lot of data-dependent
fragmentation which the client may understand, but the browser-based
picker does not.

I'm suspicious that having a more generic handle-all-invocations
web-based WIA that requires a network fetch on every intent invocation
is a performance penalty that in today's networking environment,
browsers are going to be extremely reluctant to allow. Does that
constraint push us towards an extension-only kind of support? Or
perhaps an appcache'd page?


On Thu, Jun 7, 2012 at 9:15 AM, Jean-Claude Dufourd
<jean-claude.dufourd@telecom-paristech.fr> wrote:
> Dear all,
>
> Here is a rewrite of section 4 (before 4.1), in an attempt to make more
> concrete my comments on the current state of the spec and its single focus
> on the UA:
> http://perso.enst.fr/~dufourd/wia_integrated.htm
>
> To show what is new and what is old, here is another version with Word
> revision marks exported to HTML:
> http://perso.enst.fr/~dufourd/uaTOwia.htm
> There are spurious marks (such as one "should" replaced by a... "should").
> But I hope it makes it easier to see the changes.
> Best regards
> JC
>
> --
> JC Dufourd
> Directeur d'Etudes/Professor
> Groupe Multimedia/Multimedia Group
> Traitement du Signal et Images/Signal and Image Processing
> Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
> Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
>
>

Received on Wednesday, 13 June 2012 04:57:26 UTC