Re: [Powerbox] Q's on the proposal

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