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

Re: Why aren't most devices virtual web services?

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 13 Jan 2010 02:12:24 -0800
Message-ID: <7789133a1001130212j7be2aa26yf1a68c0ff50d009f@mail.gmail.com>
To: richard.tibbett@orange-ftgroup.com
Cc: erights@google.com, public-device-apis@w3.org
On Mon, Jan 11, 2010 at 3:20 AM,  <richard.tibbett@orange-ftgroup.com> wrote:
> Does this not assume, in the case that a local device is providing these
> APIs, that the local device is running a local web server?

You're confusing the design of the APIs with their implementation.
Content using these APIs will issues requests for various URLs (e.g.,
via XMLHttpRequest).  The user agent will deliver the responses (e.g.,
contact lists) or enact modifications to persistent state (e.g., add a

One way to implement this is with a local web server.  Another way to
implement is to generate the responses to the URLs directly in the
user agent.  For example, most desktop browsers allow content to read
the file system via file:// URLs.  Would you say that these user
agents contain a local web server?  I think it's more appropriate to
say that they generate responses for requests for file URLs

> Again, web services denotes the requirement of a web server which, for
> local device access (such as for System Info), is not widespread in
> existing browser architecture. This will present issues with backward
> compatibility.

This sentence mystifies me.  I'm not entirely sure what System Info
is, but it sounds like it might be similar to the information Linux
places in the /proc file system.  When you run Firefox on Linux, this
information is available via XMLHttpRequest (subject to security
restrictions).  For example, at the URL, <file:///proc/cpuinfo>.  I
don't see any backward compatibility issues here.

Received on Wednesday, 13 January 2010 10:13:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC