Re: rewrite of section 4

On Wed, Jun 13, 2012 at 2:22 AM, Jean-Claude Dufourd
<jean-claude.dufourd@telecom-paristech.fr> wrote:
> On 13/6/12 06:56 , Greg Billock wrote:
>>
>> 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.
>
> JCD: The additional APIs in my rewrite are not meant to be accessible to the
> pages.
> They are meant to be usable only by a browser extension.
> Sorry about not making that clearer.

No worries. I agree with you that an extension mechanism around
intents is very useful. (But I'm biased that way. :-)) Perhaps this
belongs in the best practices section, though, instead of section 4?
(That is, a non-normative section describing the extension
functionality that UAs should expose -- they will have different
trade-offs to make in terms of the overall extension API and how they
all work together; I don't think we should require a particular
extension API method signature or interaction style.)

>
>
>>
>> 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.
>
> JCD: I totally agree about the confidentiality.
>
>
>>
>> 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?
>>
>>
> JCD: I do not see a use case for a generic, web-based WIA. I share your
> misgivings about requiring a network fetch for every intent invocation.
> I see a use case for a browser extension providing different styles of
> enhancements over the browser-default WIA.
> Example 1: a WIA that defines hierarchical intent directories, first looking
> into my own set of intents, then looking into my family's, then looking into
> home-wide directory (including registered guests).
> Example 2: a WIA that delegates all the intent processing to a secure,
> policy-checking, webinos Personal Zone Hub
>
> Thanks and 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 Monday, 18 June 2012 19:22:21 UTC