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 11:32:28 UTC