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

Re: Devices as Virtual Web Services

From: Robin Berjon <robin@berjon.com>
Date: Wed, 10 Feb 2010 14:13:40 +0100
Cc: public-device-apis@w3.org
Message-Id: <6281C0AA-BE1C-4A77-95CE-480925FDD473@berjon.com>
To: Thomas Roessler <tlr@w3.org>
On Feb 10, 2010, at 13:51 , Thomas Roessler wrote:
> On 10 Feb 2010, at 13:48, Robin Berjon wrote:
>> On Feb 10, 2010, at 13:25 , Thomas Roessler wrote:
>>> It's also not clear that one couldn't fake a web server within the browser (exposing the RESTFUL API to the JavaScript environment) without ever implementing an HTTP server in the process.
>> Actually that can indeed be done by wrapping the XHR object (or more cleanly, by specialising it). My concern here is that you then sort of have to support all manners of HTTP semantics if you want to do it "right" (for rather pedantic values of right), but on the other hand you reach 80/20 very quickly.
> Well, you wouldn't need to represent HTTP semantics that are masked away by XHR anyway, which probably takes away much of the 20% you don't really want to do.

Well, it depends on what you're doing  XHR doesn't mask away all that much beyond syntax (there's still expected behaviour). Just a simple example: what if there's an If-Modified-Since header set? Is it okay to always return a 200 nevertheless? What if the 200 has a Last-Modified that should've implied a 304? Is it conceivable that someone might have relied on that being consistent and subsequently fail?

> The most interesting question is probably how to model authorization for access to these resources if (a) they're actually implemented through HTTP, and (b) there are several users at one IP address or host name.
> I sense a use case for OAuth.

Yes, I would love to see something done in this area. Our friends from Google have been working on something here but they haven't had a chance to send it in yet (*nudge* *nudge*).

Robin Berjon - http://berjon.com/
Received on Wednesday, 10 February 2010 13:14:10 UTC

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