Re: Devices as Virtual Web Services

+1 (not as chair)

It would help me to understand in more detail exactly how the REST  
approach would deal with the various concerns raised by Paddy, and in  
fact also the concerns given Robin's example that I commented on  
earlier.

I also note that the group was chartered to produce the API  
definitions so this discussion is a little late, although worth  
understanding.

regards, Frederick

Frederick Hirsch
Nokia



On Jan 27, 2010, at 12:12 AM, ext Paddy Byers wrote:

> 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

Received on Wednesday, 27 January 2010 13:17:12 UTC