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

Hi,

>>people would want us to make it a generic mechanism that could apply to any
>>interface.
I think that also
"...people would want us to make it a generic mechanism that could apply to any
URL..." :)

BONDI [1] has the concept of downloadable implementation of the interface.
I.e. the interface is known, just the implementation (a dll, since it is about real device APIs) has to be downloaded.
In case of RESTful interfaces, the implementation is only some JS, so it may be realizable much easier (what about security model?).

Kenton's ideas seems to assume that the interface is unknown as well, or?
urlToObject() tells me that we have URL/resource and we need interface that enables using it.
But to use it, we should have some assumption wrt the actual interface, since we want to use it in the web app.
Otherwise it is just the standard model where we include the .js files in the web app and use the API specified there.

>>dealing with synchronous APIs
There is already PendingOperation in [2] and PendingOp defined in [3].
ProgressEvents could also help. More patterns will probably come.

There seems to be little difference between
urlToObject(url, interface)
and existing mechanisms of inclusion of the .js file, or?
UA only needs to provide XHR, I think.

Thanks,
Marcin

[1] http://bondi.omtp.org/1.1/CR/
[2] http://bondi.omtp.org/1.1/CR/apis/bondi.html#::bondi::PendingOperation
[3] http://dev.w3.org/2009/dap/device/
________________________________________
From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Ian Hickson [ian@hixie.ch]
Sent: Thursday, January 14, 2010 11:40 PM
To: Kenton Varda
Cc: John Kemp; Robin Berjon; Ilkka Oksanen; Mark S. Miller; public-device-apis@w3.org Policy WG
Subject: Re: Why aren't most devices virtual web services?

On Thu, 14 Jan 2010, Kenton Varda wrote:
>
> What I was imagining is that UAs would provide a function like:
>   urlToObject(url, interface);
>
> "interface" would be a (URL to a?) definition of the interface, perhaps
> in WebIDL or maybe in some equivalent language.  "url" points to the
> RESTful API representing a resource implementing this interface.
> urlToObject() returns an object implementing the WebIDL interface in
> terms of the RESTful interface.  We then define some standard for this
> mapping.
>
> For the record, I personally don't have any problem with only providing
> the REST API with no automatic conversion to something more friendly.
> But if some people are worried that using XHR directly is too much of a
> pain -- and making clients download helper libraries is too expensive --
> then maybe a standard urlToObject() would solve their problem.

That would certainly be interesting, though if we did that I expect people
would want us to make it a generic mechanism that could apply to any
interface. This is quite the can of worms, though, with things like
dealing with synchronous APIs, etc.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Thursday, 14 January 2010 23:38:51 UTC