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

On 13th Jan 2010 at 10:12am, Adam Barth wrote:
> 
> 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).
> 

It's an issue of API abstraction from the underlying delivery mechanism
via a widely supported client-side web technology and having the choice
to implement the underlying delivery mechanism as XHR or otherwise.

Local XHR isn't the magic bullet either. The user experience and
implementation questions of authorisation and privacy of device access
remain.

> 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.
> 

With a Javascript API another two options are that anyone could
implement the (e.g. missing) APIs as a browser extension or as a e.g
NPAPI plugin.

If we went with local XHR and browsers did not implement this model
within the browser itself, the paradigm shifts away from Device APIs to
Web APIs, which is nice but, in my understanding, this is already within
the current scope albeit with Javascript abstraction of that underlying
delivery mechanism.

The premise is then that with Javascript abstraction the implementation
choices become greater and the design is decoupled from any browser
evolution or roadmap. It provides room for innovation and implementation
around the browser product itself and maintains a suitable and widely
understood paradigm for interaction with any device-based products.

> > 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.

Ah, I could have included a link. The latest DAP System Information API
Editor's Draft is available here [1].

>  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.
> 

I understand. The intention would be to:

- make the URL requested platform independent
- make the URL point to a dynamic entity (e.g. similar to a Server-side
programming access point)
- provide an OAuth-style authorisation mechanism on the client-side
- make the URL return XML? JSON? RSS? ATOM?

As mentioned previously, I wonder about Server-push issues, in which
case:

- make the implementation behind the URL capable of handling
long-running XHR requests without inpacting on CPU resources.

It sounds like a lot of items that could be mitigated/parsed with some
intermediary processing point such as the current Javascript-based
model.



It's worth further discussion. Perhaps an advocate of this approach
could provide more concrete details of how this model would work
client-side, and how it matches the pros of the current abstracted
Javascript model approach and provides the same (but preferably more)
ability to innovate on the implementation details. For now, I advocating
the existing model as the best approach for the reasons included here.

> Adam
> 

Best Regards,

Richard


[1] http://dev.w3.org/2009/dap/system-info/


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

Received on Wednesday, 13 January 2010 11:55:17 UTC