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

Hi Mark,

Welcome to the group. I've included some thoughts below. My argument is
for the abtraction by one layer from your proposal. i.e. API content
delivery vs. API content interaction.

Kind Regards,

Richard

On 8th Jan 2010 at 2:48am, Mark S. Miller wrote:
>	The case is clearest for contacts. Why should authorizing
Facebook to access my local contacts be different than, for example,
authorizing Facebook to access my gmail contacts?

This use case is available in the current Contacts API spec [1] and my
short answer is that it shouldn't be (and AFAIK isn't) different. Taking
your use cases, Facebook can access your gmail/yahoo/etc contacts via
OAuth w/ normalized Contacts API integration.

My long answer is that the current APIs enable users to access device
information - whatever the definition of device is. I'm very flexible on
this term. The APIs are accounting for the possibility that the term
'device' can mean a local repository or a remote repository - namely:
local device access through browser chrome or remote service access
through e.g. Oauth-based JS shims. There is asynchronous operation on
any methods that could require remote service or device interaction - we
don't state exactly which is required - we leave that as a design
decision.

> ... we should merely provide device APIs as RESTful GET/POST APIs...

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? Is it not
better to allow implementers to make design choices whether to write
NPAPI-based browser plugins and/or web-based service JS shims (and/or
local RESTful implementations if suitable) to this problem - whichever
is most suited to the mode courant? 

I don't disagree that RESTful APIs is a viable way to deliver e.g.
contacts and calendar information (and a host of other information) with
the view of delivering info from a web service. The intention of
defining a Javascript-based API is to enable the abstraction of
content-delivery (Remove Web Server [JSON/XML/... via XHR],
Open/Proprietary Local Device interaction [NPAPI], Local Web Server
[REST APIs e.g. via XHR]) vs. actual contact-interaction (normalized JS
API). 

The current API focuses on the latter.

> For some devices, an objection that has been raised: receiving and
reacting to notifications from RESTful web services is awkward. 

This is out of scope. For web services we've got COMET, BAYEUX w/ Web
Server Continuations for XHR-based implementations and/or Server-sent
Events from HTML5 - which as you state is entirely a problem to be
solved with web services in general. For local services we've got
proprietary push mechanisms via e.g. NPAPI.

> ...devices can again be made polymorphic with web services providing
similar functionality.

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.

> Let's please avoid introducing unnecessary cases into web standards.
KISS.

I agree but preferably not at the expense of introducing inequality
between the implementability for remote web-based services over local
device-based services - both of which should be in scope.

Kind Regards,

Richard


*********************************
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 Monday, 11 January 2010 11:20:43 UTC