Re: Devices as Virtual Web Services

Hi,

As for the goal of interoperability, I think that goal is much better served
> by basing the standards on REST.  HTTP is already a standard protocol with
> standard access control mechanisms, and its use is well-understood.
>

I don't understand how those standard access control mechanims are relevant.

I understand that XHR or whatever other facilities we are talking about are
well understood, and contain "policy enforcement" functionality (in XACML
terminology), whose implementation, and impact on the developer, are well
understood. But I don't see how their existing "policy decision"
functionality is at all applicable.


> By exposing devices as REST services, we make the problem of implementing a
> new device equivalent to the problem of writing a new web service, for which
> many tools and much expertise already exist. Exposing a new device may be as
> easy as providing a local web server implementing it, perhaps with no
> browser changes needed at all.
>

That's assuming that such local web server is a viable implementation route,
considering performance and efficiency issues. If it is not viable, then in
fact the problem of implementing a new device may even have been made harder
- for example, does it require a new extension mechanism within the browser
to support new URI schemes / protocols?

Providing access to non-local devices and writing non-browser-based software
> that accesses devices both become trivial even though those were not our
> intentions.  I think all of this means that a standard based on REST is
> likely to get much wider use than a standard based on Javascript APIs.  As a
> nice bonus, creating the standard itself would be much less work.
>

Again, I don't really see how creating the standard is easier.

The key thing that has to be defined in either case is the abstract
interface itself, expressed for example in WebIDL. Once this is defined, I
don't see how expressing that as a REST API is less work than simply
providing the standard JavaScript binding - in fact, again, there is more
work to do (which I admit can all be generic, and not API-specific) to
define how it is represented concretely in a response document.

Thanks - Paddy