- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 13 Jan 2010 02:12:24 -0800
- 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 contact). 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 internally. > 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. Adam
Received on Wednesday, 13 January 2010 10:13:17 UTC