W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

Re: [Powerbox] Q's on the proposal

From: Mark Seaborn <mseaborn@chromium.org>
Date: Thu, 25 Feb 2010 18:31:25 +0000
Message-ID: <e1cf9ca11002251031s5db72a60jaf3b0d9fc55296e8@mail.gmail.com>
To: public-device-apis@w3.org
[Resending after subscribing the correct e-mail address.  Sorry if a
duplicate appears.]

On Wed, Feb 24, 2010 at 6:31 PM, <richard.tibbett@orange-ftgroup.com> wrote:
>
> 1. <input ...> does not degrade nicely in older UAs. (this was raised on
> the conf. call but included for completion).
>
> If the <input type="file" ...> DAP extensions are not supported in older
> browsers the degradation is to a file picker. This does not make sense
> for a number of APIs such as video, contacts, calendar, system info.
>
> In the current JS API proposals a web developer can check for support of
> an API before invoking it via Javascript. The test for API support and
> the API itself are the same object which is a concious API design
> consideration.

For feature testing purposes we could add an attribute to the <input>
DOM element (as Anssi Kostiainen suggested), or add an attribute to
the navigator object, e.g. navigator.powerbox (as suggested in the
teleconference minutes from yesterday).


> 2. Could API Providers be defined as OpenSearch-like documents rather
> than JSON-style documents?

The encoding of requests to a resource is up to the resource type, so
yes.  The Powerbox is agnostic about the encoding that is used.  The
use of JSON in the spec is just an example.


> 3. Does reducing the problem to XHR/REST requires the webapp to address
> a single Provider resource at a time?
>
> My understanding of the Powerbox proposal is on calling a specific
> Provider per XHR request.

That's basically right.

In principle, if a web app notices that two resource URLs have the
same hostname, it could batch up requests to these resources and send
them in a single XHR request, instead of in two separate XHR requests,
if it knows that the resources implement a protocol that supports
this.  I'm not sure if this would be useful for any of the current
Powerbox use cases though.


> Could a webapp address a single endpoint that delegates to all installed
> Providers (via XHR/JSON) depending on the user's Provider selection?

I don't entirely understand this.  What would the single endpoint be?
If it delegates to all installed providers, what is the purpose of the
user making a provider selection?


> 4. Is a two step usage process for user interaction required for
> Powerbox use?
>
>  - on invocation of the <input ...> element, select a provider to use
> in a user dialog,
>  - select provider artifacts (objects) in a user dialog and review the
> provider artifacts to return to the webapp.
>
> In the current Contacts API proposal, we have the usage interaction down
> to one non-modal 'contacts picker' dialog while fulfilling the same use
> cases. Does the Powerbox approach support the same single interaction
> principle?

The Powerbox can have a one-step or two-step interaction depending on
the types of provider that are registered.

The typical scenario is that the Powerbox presents a list of
providers.  If the user picks a non-interactive provider, the resource
is granted to the requesting web app without further interaction (one
step).  If the user picks an interactive provider, the browser opens a
new tab in which the user can interact with the provider (two or more
steps).

Taking the example of uploading images:
 * A Flickr account could be registered as an interactive provider.
When the user selects this provider, it opens a view in which the user
can pick an image from the account.
 * It would also be possible to register an individual image as a
(non-interactive) provider.  So viewing an image in Flickr could
provide a button for registering the image as a provider.  When a web
app requests an image, this image can be selected in the Powerbox
provider list, in which case the image is granted to the requester
without further interaction.  This allows a copy-and-paste style of
interaction, with the Powerbox's provider list acting like a
clipboard.

(I sketched out something similar in an post to the cap-talk mailing
list: http://www.eros-os.org/pipermail/cap-talk/2010-February/013768.html)


For resource types where there is only one provider registered, the
browser could be configured to jump straight to the provider's tab
(assuming it is an interactive provider) without presenting a list of
providers.  Hence this is reduced to being a one step interaction.

For example, to select a file to upload, the browser can jump straight
to the local file chooser if no remote file choosers or image
capturers are configured; or image capturers could hang off a trusted
local file chooser tab.

It's OK for some providers and resource types to be given special
treatment by the browser.  It's just that there should be fallback
behaviour for resource types that the browser doesn't know about.

(I mentioned this idea previously in
http://www.eros-os.org/pipermail/cap-talk/2010-February/013767.html)

To account for this case, we could relax the language in the spec, which says:
"When a user activates a requisition control, the Powerbox MUST enable
user selection of a registered Provider."
Maybe this should be a "SHOULD" instead of a "MUST".


> 5. No specific user interaction provisions or recommendations for CRUD
> operations have been detailed in the Powerbox examples.
>
> While an XHR/RESTful approach naturally includes getting data, deleting
> data and saving data back to a Provider the user experience/interaction
> required in initiating those processes is a little unclear. I anticipate
> this will be an async dialog allowing the user to review the information
> to be saved and then to select 'Allow'/'Deny'.

I have mostly been assuming that if the resource is mutable, then once
the customer has been granted access to the resource via the Powerbox,
the customer would be able to send requests (e.g. POSTs) to modify it
without involving user interaction.  We can handle this case fine.

However, if there are operations that the customer can initiate that
require user interaction, I can see two ways we could handle this:
 * The resource could give the customer a confirmation URL to redirect
to or to display in an iframe.  (However, the iframe case is
problematic because of clickjacking.)  This is similar to how OAuth
works, in the sense that it would rely on the confirmation URL
requiring cookies or other ambient credentials.
 * When the resource receives the customer's request, it initiates an
interaction with the user through some route that does not depend on
the customer.  For example, if the resource is provided by a local
service, it could display a notification in the browser's trusted
chrome.  This sounds similar to the async Allow/Deny dialog you
suggest above (which I assume is for a local Contacts service?).  The
disadvantage of my suggestion is that the browser does not know
whether the initiator is in the foreground.  If the initiator is in
the foreground, displaying only a notification is too cautious.  If
the initiator is in the background, displaying an asynchronous
notification could be too intrusive.

This question could arise for a hypothetical local storage service.
Suppose the Powerbox is used to grant access to quantities of local
storage.  Suppose a web app requests local storage to use as a cache,
and the user initially grants 1Gb.  Later, it starts to run out of
storage and so wishes to request some more.  The user might wish to
increase the limit to 2Gb, but it would be useful for the web app to
have a way to initiate the interaction to increase the limit.
Although the web app could initiate a new Powerbox request for
storage, this would create a new grant that is independent from the
first (and potentially on a different storage service provider), which
would complicate review and revocation of storage grants.

Cheers,
Mark
Received on Friday, 26 February 2010 13:49:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC