- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Thu, 13 Oct 2011 12:45:45 +0200
- To: "Josh Soref" <jsoref@rim.com>, "Dave Raggett" <dsr@w3.org>
- Cc: "C.Stevens@CableLabs.com" <C.Stevens@cablelabs.com>, "blsaws@gmail.com" <blsaws@gmail.com>, "anssi.kostiainen@nokia.com" <anssi.kostiainen@nokia.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
On Thu, 13 Oct 2011 12:22:27 +0200, Dave Raggett <dsr@w3.org> wrote: > Woudn't CORS be applicable here? CORS is applicable and cover some use cases (we even mention it in our draft I believe). Does not address support for legacy devices though. I think the thread-off we propose is good: if you want to support legacy devices, you need some support from the user agent to workaround same origin restrictions. For those devices that support CORS, the only thing left to be handled by the user agent is discovery (that for old UA may be implemented with a plugin) Not that in some use cases the same origin restriction is not even an issue; e.g. we have seen some demos during the last workshop where the "application" was running in a web server on the device (the presentationURL of UPnP). In that case you will be able to talk to the application from your PC without problem. You still need discovery to find that URL though /g > On 12/10/11 21:10, Josh Soref wrote: >> Technically a stub implementation could only expose e.g. Public servers >> reachable from the same origin's backend. It would still be a valid >> implementation of the general api. Sure it wouldn't give access to >> local (physical), local (bluetooth), or local (subnet) elements, but it >> would let the user discover and select "sensors" (e.g. I might select >> the YYZ weather station instead of the LAX weather station). This could >> easily be quite valuable to me even though it might not quite match >> someone's expectation. > -- Giuseppe Pascale TV & Connected Devices Opera Software
Received on Thursday, 13 October 2011 10:46:27 UTC