RE: [Powerbox] Q's on the proposal

On Tues, 2 Mar 2010 at 11:29, Richard Tibbett wrote:
> 
> On Sun, 28 Feb 2010 at 19:45, Mark Seaborn <mseaborn@chromium.org>
> wrote:
> > 
> > 	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.
> > 	
> 
> I would say that we do want a Powerbox to know how to 
> interpret the data being sent and received for a finite set 
> of API use cases. Being data-aware provides more granular 
> filtering, parameterization, richer opt-in/review interfaces 
> and better security and privacy controls - IMO all of the 
> challenges of this working group. 
> 
> It should be possible for a webapp to request specific sets 
> of an object's attributes and to receive only those requested 
> attributes in response - and allow all that to happen in a 
> consistent way across Provider implementors. It should do all 
> that without unneccessarily exposing a whole Blob/File object 
> when only a slice of that object will do - and if only a 
> slice will do then why not sufficiently structure that slice 
> of data so its individual components can be used at runtime 
> by the developer in their webapp?
> 
> So I question whether returning File-like objects to an input 
> elements 'value' attribute is going to cut it for all DAP API 
> use cases.
> 

That wasn't intended to be entirely negative - the principles on which
Powerbox is built are highly relevant. The principle that once the
'Device' paradigm includes web-based service providers that web-based
XHR/RESTful communications must be considered is inevitable. The
principle that web-based service providers and native service providers
need to play nicely together is important - not least to get to some
form of group concensus. I disagree on two counts: that the <input file>
element is the best approach for Powerbox interaction and that a
Powerbox should act as a dumb-pipe in data exchanged between a webapp
and service provider (for the reasons in my previous mail).

Below I attach a very early proposal for 'OpenProvider' - a more
granular data and context aware Powerbox counter-proposal - built on
many of the same principles as Powerbox but creating a chain of
*structured information exchange* from a web app, via an OpenProvider
container (which is much like a Powerbox, implemented in the UA) to
local/web services and vice versa.

OpenProvider expects responses of a certain format from all providers
and provides structured slices of data back to a user depending on any
number of security and privacy mechanisms in place. 

If there is interest in this approach I will spec this up in the coming
days. Comments will be gratefully received :-)

Cheers,

Richard


---------------------------------------------------------------

OpenProvider Proposal for A/V Capture
=====================================

This is an early proposal for a format called 'OpenProvider', explained
through the use case of Audio/Video Capture.

OpenProvider draws some parallels with Powerbox - the intention of
OpenProvider is to map Javascript APIs to RESTful interfaces with
structured data exchange.

* An OpenProvider container can delegate an API request to the user
selected Provider - OpenProvider documents are standalone documents that
describe the public interface(s) of a service provider so that an
OpenProvider container can act on those resources and return structured
responses to the callee.

* An OpenProvider document is installable in an OpenProvider container -
via Javascript bindings (e.g. window.external.AddAPIProvider(...) - tbd)
/ manually.

* OpenProvider documents act on granualar input and output information -
A webapp can request specific sets of object attributes and will
returned only subsetted information that has been requested by the
webapp and authorised by the user - not whole Blobs of data.

* An OpenProvider container (implemented in the UA) is response-aware -
this allows structured and formatted response data to be returned from
Web-based Providers to WebApps instead of Blobs of data. This provides
greater granularity of data and a structured format for webapps to query
on callback success.

OpenProvider Capture API Usage Example
--------------------------------------

1. Web App requests a video capture. A Javsscript-based API is condusive
to setting and providing capture options to an OpenProvider container:

navigator.device.captureVideo(successCB, 1, 20);

2. OpenProvider Container handles this request and lets the user choose
an installed OpenProvider.

3. OpenProvider Container provides input parameters from the web app to
the user-selected OpenProvider (from step 2).

4. OpenProvider document executes request (with the webapp provided
parameters) against the service defined therein.

5. A response is received from the service. The OpenProvider Container
parses this response according to the OpenProvider type and triggers the
successCB callback (defined in step 1) with the structured response
data. In the case of this example, the response data include the URL of
the video uploaded to the web service defined in the OpenProvider
document (see below).

...

OpenProvider Capture API Document Syntax
----------------------------------------

The following is an example OpenProvider document for capturing video
content locally and uploading the result to a web service:

 <?xml version="1.0" encoding="UTF-8"?>
 <OpenProviderDescription
xmlns="http://w3.org/2009/dap/openprovider/1.0/"
     xmlns:capture="http://w3.org/2009/dap/openprovider/capture/1.1/">
   <ShortName>Example Inc. Video Provider</ShortName>
   <Description>Capture and Upload a video to Example.com</Description>
   <capture:Input type="text/html"
	
template="chrome://capture?limit={captureLimit}&duration={captureMaxDura
tion}"
	capture:Id="captureContent">
	   <capture:Output
xmlns:parameters="http://w3.org/2009/dap/openprovider/parameters/1.0/"
	        type="text/html"
		template="http://example.com/av/upload"
		parameters:method="POST"
		parameters:enctype="application/x-www-form-urlencoded">
		   <parameters:Parameter name="content"
value="{captureContent}"/>
		   <parameters:Parameter name="title"
value="{captureTitle?}"/>
		   <parameters:Parameter name="description"
value="{captureDescription?}"/>
		   <parameters:Parameter name="date"
value="{captureDate}"/>
	   </capture:Output>
   </capture:Input>
   <OutputEncoding>UTF-8</OutputEncoding>
   <InputEncoding>UTF-8</InputEncoding>
 </OpenProviderDescription>


OpenProvider URL template syntax
--------------------------------

The OpenProvider URL template format can be used to represent a
parameterized form of the URL by which a resource is queried.

The provider client (i.e. the Powerbox) will process the URL template
and attempt to replace each instance of a template parameter, generally
represented in the form {name}, with a value provided at runtime.

* Substitution rules *

The provider client must replace every instance of a template parameter
with a value before the resource request is performed.

If a provider wishes to indicate that a template parameter is optional
and can be replaced with the empty string, then the "?" notation
described in the section on optional template parameters should be used.



OpenProvider description Elements for Capture API
-------------------------------------------------

* The "Input" Element *
 
Describes an interface by which a client can setup and capture
audio/video input. This element can point to either a local or remote
resource.

* The "Output" Element *

Describes an optional interface by which a client can trigger the push
of any captured audio/video input, such as uploading captureContent to a
server or saving audio/video input to the device.




OpenProvider Capture API parameters
-----------------------------------

* The 'captureLimit' parameter *

Contains a numerical number that holds the upper limit of audio/video
clips that the user can record.

This attribute will be processed according to the rules of the
[OpenProvider URL template syntax]. This parameter is substituted with
the 'limit' parameter value provided by the web app via the Capture API.

* The 'captureMaxDuration' parameter *

Contains a numerical number that holds the maximum duration of a single
clip (in milliseconds) that the user can record.

This attribute will be processed according to the rules of the
[OpenProvider URL template syntax]. This parameter is substituted with
the 'duration' parameter value provided by the web app via the Capture
API.

* The 'captureContent' parameter *

Contains a string that holds the serialized data capture item data.

This attribute will be processed according to the rules of the
[OpenProvider URL template syntax]. This parameter will be filled by
obtaining the raw 'uri' data returned from the video:Input 'uri' and
serializing this data for POSTing to the requested resource.

* The 'captureTitle' parameter *

Contains a string that holds an optional title for the capture item.

This attribute will be processed according to the rules of the
[OpenProvider URL template syntax]. This parameter MAY be provided if
the video capture interface presented to the user allowed for a name to
be given to the current clip.

* The 'captureDescription' parameter *

Contains a string that holds an optional description for the capture
item. This parameter MAY be provided if the video capture interface
presented to the user allowed a description to be given to the current
clip.

This attribute will be processed according to the rules of the
[OpenProvider URL template syntax].

* The 'captureDate' parameter *

Contains a string that must be used to pass the current date and time.
If no captureDate is propagated from the video capture interface, the
OpenProvider container MUST generate and provide a ATOM formatted date
object for this parameter.



OpenProvider Response Elements for Capture API Input
----------------------------------------------------

* Example of OpenProvider Capture Input response elements in JSON *

[this will be well-defined WebIDL-to-JSON mapping specific to the
Javascript Capture API]

{[
   {
      'uri': 'chrome://capture/?v=342so9e1sq', 
      'format': {
              'type': 'video/h264',
	      'width': 800,
	      'height': 600,
	      'duration': 42000.000
      }
   },
   ...
]}

[...etc for other formats]

If no Output elements are specified, Capture API Input Response Elements
MUST be returned via the registered Javascript callback to the
requesting web application.


OpenProvider Response Elements for Capture API Output
-----------------------------------------------------

* Example of OpenProvider Capture Output response elements in JSON *

{[
   {
      'uri': 'http://example.com/av/streams/3ds2-saf5-223e-dfds-3334', 
      'format': {
              'type': 'video/h264',
	      'width': 800,
	      'height': 600,
	      'duration': 42000.000
      }
   },
   ...
]}

[...etc for other formats]

If Output elements are specified, Capture API Output Response Elements
MUST be returned via the registered Javascript callback to the
requesting web application.

Received on Tuesday, 2 March 2010 12:31:54 UTC