W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

Re: [Powerbox] A RESTful proposal for Web enabling devices

From: Kenton Varda <kenton@google.com>
Date: Tue, 23 Feb 2010 13:37:56 -0800
Message-ID: <4112ecad1002231337h7ef6d4a4k3a8d04c9126a88cd@mail.gmail.com>
To: Tyler Close <tyler.close@gmail.com>
Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
I talked to Tyler and I think we've resolved all my issues as follows:

On Mon, Feb 22, 2010 at 4:09 PM, Kenton Varda <kenton@google.com> wrote:

> *Interactive Providers*
>

This can be solved by:
- Requests to the provided URL block until the user has finished interacting
with the provider.
- If desired, an HTTP redirect can then be used to direct requests to a
resource at a different URL.


> *Type of provided resource*
>

I was thinking of a provider being something like "Gmail contact list
provider" or "Local webcam feed provider".  Tyler was imagining providers
being much courser:  "Google" or "Local machine".  When the user selects
such a provider, the provider would then send back an interactive interface
allowing the user to select a particular resource.  That interface can
freely filter the resource list based on the requested type.  So, the
powerbox itself does not need to do any filtering of the provider list.


> *"Overloading" class*
>

Tyler says he updated the document to explicitly state that classes must be
globally unique identifiers beginning with the domain name (e.g. "org.w3c").
 I guess this is good enough to satisfy me.  I still think this information
belongs in the "accept" attribute but I don't see any huge problem with
putting it in "class".


> *Metadata*
>

Didn't discuss but seems like a no-brainer.


> *Membranes*
>

Given Tyler's vision of course providers, it makes sense for the provider to
be the one that deals with membranes.  I'm a little disappointed that there
won't be a unified UI that users could use to see all their grants, but this
keeps the powerbox very simple.

My particular rule about the requester not trying to identify the provider
based on the URL content seems to be a special case of the opacity
principle:
  http://www.w3.org/DesignIssues/Axioms.html#opaque


> *Prototyping*
>

I'm planning to start working on a prototype.
Received on Tuesday, 23 February 2010 21:38:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC