RE: SEMC questions/comments on Powerbox

Hi Mark and thanks for your reply,

On my question 1 I am unfortunately still puzzled. You describe different ways to transfer parameters to the Resource Provider by XHR to the Provided Resource URL. However, how should the data be formatted? Both the Customer and the Resource Provider need some kind of agreement on the data structure. Don't we need standardization of REST APIs? Or do anticipate that some kind of "provider description", in xml or json, that defines the API? Some examples of "write resource" scenarios would really be helpful.

For question 2 I interpret your answer so that the Resource Provider immediately returns a Provide Resource URL with the Location header of the UMP "Resource Provisioning" response. This URL could be considered as a "preliminary URL" and for interactive providers a dialogue with the user is executed to select the actual resource. This means that Resource Provider must "remember" the user's selection when it finally returns the Resource as a response to the UMP GET. Correct?

Furthermore, do you anticipate standardization of a set of new MIME - types to cover local resources, for example sensors?

Regards
  Claes


> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Mark Seaborn
> Sent: torsdag den 11 mars 2010 01:06
> To: public-device-apis@w3.org
> Subject: Re: SEMC questions/comments on Powerbox
> 
> On Wed, Mar 10, 2010 at 11:03 AM, Nilsson, Claes1
> <Claes1.Nilsson@sonyericsson.com> wrote:
> > 1.       The use cases and discussions around Powerbox have so far
> been
> > focused on "get resource" scenarios. To me it is still unclear how
> "write
> > resource" scenarios are handled. According to the Powerbox draft
> > specification a resource URL is provided to Powerbox. However, how
> are
> > parameters defined that for example are needed for a "create new
> contact"
> > use case?
> 
> There are a couple of ways this can be handled:
> 
> 1) The resource that is granted can be a "mutable contacts list".  The
> customer web app would get back a resource URL to which it sends XHR
> messages to add new contacts.  These messages would be handled without
> interaction with the user.
> 
> It would, optionally, be possible for the contacts list provider to
> record which customer web app added which contacts list entry:  The
> provider can associate each "contacts list" resource URL with the
> identity of the customer app to which the URL was granted, based on
> the identity information the Powerbox sends to the provider at
> resource provision time.
> 
> 2) The resource that is granted can be a one-off "add entries to
> contacts list" resource.  The customer web app gets a resource URL to
> which it sends a single XHR message containing the entries it wants to
> add.  (An alternative interface is for the customer to include this
> data in the resource requisition arguments that the Powerbox will send
> to the provider in the resource provision message -- it depends how
> large the data is.)  The provider can be an interactive provider which
> presents the data to the user to ask for confirmation to add it.
> Alternatively, a non-interactive provider could add the contacts
> entries without confirmation.  The customer web app sees the same XHR
> interface whether the provider is interactive or not.
> 
> Similar interfaces could be used for adding an event to a calendar, or
> even for sending a file to a printer.
> 
> There is a spectrum of choices here:
> 
> - interactive (requiring review/confirmation) or non-interactive
> - write-only or read-write access
> - one-off or ongoing access
> 
> 
> > 2.       There have been discussions on interactive providers and how
> the
> > resulting Provided Resource URL should point at the exact Resource (s)
> that
> > are selected by the user.
> > - Is it up to Powerbox to modify the Provided Resource URL that is
> received
> > with the Location header as a result of the user interaction?
> 
> No, the Powerbox is expected to pass the resource URL to the customer
> web app verbatim.  The provider can change the effect that the
> resource URL has based on its interaction with the user, however.
> 
> Suppose the user selects a file-chooser provider.  The provider would
> return a resource URL immediately, before the user has chosen a file.
> After the user has chosen a file, a GET to the resource URL would
> return the file's contents (or redirect to another URL that has the
> file's contents).  Before the user has chosen a file, a GET would wait
> for the user to make a choice before returning a response; i.e. a
> hanging GET.
> 
> Using a hanging GET might not be ideal -- it might be worthwhile
> finding a way to signal that the resource is ready through the browser
> instead.  But in abstract, the resource URL acts like a promise object
> -- to use the term from the E programming language -- that resolves to
> whatever resource the user chooses.
> 
> Regards,
> Mark
>

Received on Thursday, 11 March 2010 15:05:09 UTC