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

[Powerbox] Q's on the proposal

From: <richard.tibbett@orange-ftgroup.com>
Date: Wed, 24 Feb 2010 19:31:04 +0100
Message-ID: <3222_1267036269_4B85706D_3222_49707_1_355A518BC0575547B2A3D6773AAF8EEF995841@ftrdmel1>
To: <public-device-apis@w3.org>

I wanted to touch on a few other aspects of the Powerbox proposal on the
conf. call today but I was minuting and we...kind of ran out of time.
Therefore, please find this feedback included below.

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

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

In the existing Contact API we stated that the underlying implementation
is of a unified address book (or multiple address books available as
part of a unified callback) regardless of the actual selection of which
address book(s) to use.

For the Provider documents, I'd like to propose we define
OpenSearch-style [1] [2] API Providers in parallel (but seperately) to
the Powerbox definition. 

I wouldn't really advertise API Providers in the same way as RSS feeds
are advertised. A user could  add new Providers for different APIs via
UA configuration by entering a URL to a given provider resource
(obtained from something like a maintained directory of available
providers) [3]. 

Alternatively a new Provider could be added via JS functions. For
OpenSearch the following JS endpoint exists in Firefox and IE7 that can
only be triggered on 'click' events and installs the OpenSearch
engineURL in to the browser: 


Could we do something similar with OpenSearch-like API Providers?

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. 

Could a webapp address a single endpoint that delegates to all installed
Providers (via XHR/JSON) depending on the user's 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

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'. That's just one very
basic UX example but it would be interesting to get the thoughts of the
Powerbox editors on roughly the UX they had in mind to initiate the
different CRUD operations on the Powerbox. It would be good to
understand if there are any differences to the UX proposals between the
Powerbox proposal and the existing JS API proposals.



[1] http://www.opensearch.org/Specifications/OpenSearch/1.1




This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
Received on Wednesday, 24 February 2010 18:31:47 UTC

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