RE: [Powerbox] Q's on the proposal

On Feb 25, 2010 at 18:31, Mark Seaborn wrote:
> 
> [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:
> > 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.
> 

I was targeting the definition of a Provider rather than any communication aspects towards that Provider and its resources. I envisioned some format, let's call it 'OpenProvider', for defining API Providers that describe the communication with an API Provider's resources according to W3C DAP defined API provider templates. The actual communication with these resources would be via whichever format(s) the Provider supported and as defined in the OpenProvider documents.

An OpenProvider would be defined with something like:

(URL = http://foo.com/ab/openproviderdescription.xml)

<openprovider xmlns="http://w3.org/dap/contacts/1.0">
	<name>Foo.com Address Book OpenProvider</name>
	<Description>Use your Foo.com address book in Device Interactions.</Description>
	<method name="find">
		<Url>
			http://foo.com/api/addressbook/find/?fields={searchFields}&filter={searchFilter?}&format=json
		</Url>
		<Method>
			GET
		</Method>
	</method>
	...
</openprovider>

...where 'searchFields' and 'searchFilter' are well-defined template parameters that are replaced with the webapp provided parameters at API runtime invocation.

As part an parcel of an OpenProvider spec we would define the response elements expected from the OpenProvider URLs on an API to API basis similar to http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_response_elements.


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" />

...and it could be 'installable' with:

window.external.AddAPIProvider('http://foo.com/ab/openproviderdescription.xml');



> 
> > 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.

Using a single API endpoint makes requesting chrome://services/photos for each request redundant. Therefore it could simply be abstracted out of the consumer-facing API while still providing what is XHR interaction with web-based services.
 


What do you think?


Thanks,

Richard


*********************************
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 Friday, 26 February 2010 16:53:07 UTC