- From: Mark Seaborn <mseaborn@chromium.org>
- Date: Sun, 28 Feb 2010 19:43:36 +0000
- To: public-device-apis@w3.org
- Message-ID: <e1cf9ca11002281143y1bd5ac2cl22b61ced44cc7c5e@mail.gmail.com>
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