- From: Greg Billock <gbillock@google.com>
- Date: Mon, 18 Jun 2012 12:21:53 -0700
- To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Cc: "public-web-intents@w3.org" <public-web-intents@w3.org>
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