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: Sun, 28 Feb 2010 19:43:36 +0000
Message-ID: <e1cf9ca11002281143y1bd5ac2cl22b61ced44cc7c5e@mail.gmail.com>
To: public-device-apis@w3.org
On Fri, Feb 26, 2010 at 4:50 PM, <richard.tibbett@orange-ftgroup.com> wrote:

> An OpenProvider could then be advertised webapp to webapp like:
>
> <link rel="api" href="http://foo.com/ab/openproviderdescription.xml"
> type="application/openproviderdescription+xml" title="Foo.com Address Book
> OpenProvider" />
>

In the Powerbox proposal, a provider URL would need to contain some
unguessable data unless you intend for your provider to be publicly
accessible.


> > > 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?
> >
>
> The single endpoint would be the browser's chrome itself which would relay
> (incidentally via XHR) to Providers only when they are selected by the user
> as part of the 'Provider selection process' described in the Powerbox
> proposal.
>
> E.g. Taking the photos example, all API requests actually point to e.g.
> chrome://services/photos. This invokes a user selection to choose your
> intended Provider(s). Depending on the user's selection the API request
> parameters get dispatched to the selected Provider(s) (and the selected
> Providers only), the requests get sent off via XHR according to the <Url>
> node provided in the OpenProvider document and, finally, the responses are
> aggregated and return as a single callback to the requesting webapp. All
> brokered by the browser.
>

I'm afraid I don't really understand what you are proposing here, but...

If the browser were responsible for aggregating responses like this it would
need to know about the protocols and data formats supported by particular
resource types.  This is something we specifically want to avoid in the
Powerbox proposal.  The Powerbox just provides a generic facility for
introducing a customer web app to a resource by passing a URL (and, for the
sake of compatibility with file upload, a blob of data) to the customer.  We
don't want the Powerbox to need to know how to interpret this data.

What kind of aggregation are you thinking of?  You mentioned Contacts
before.  In this case, isn't aggregation just a matter of concatenating
contacts lists?  Why would this need to be done in the browser?  Wouldn't
the need to combine multiple contacts lists be fairly rare?

Cheers,
Mark
Received on Sunday, 28 February 2010 19:44:07 UTC

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