- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 10 Jan 2010 06:13:19 +0000 (UTC)
- To: Kenton Varda <kenton@google.com>
- Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
On Fri, 8 Jan 2010, Kenton Varda wrote: > > > > I like this idea. It would mean, for instance, that Web-based contacts > > services (e.g. Facebook) could plug into the same API that the local > > contacts database uses. Similarly, sites could use a common Calendar > > API and the user could decide if it should use the system calendar, or > > some Web-based calendar. > > Yep, this is exactly what I was trying to suggest a couple weeks ago, > though I may have presented it poorly. I was arguing that web sites > should have the ability to expose virtual devices as web services. I > should have clarified that the way I imagined doing this is by making > devices look like web services -- not by inventing a new standard for > web services to implement things that look like local devices. > > If we do it this way, then your <device> element would presumably be > able to do exactly what I was asking for before: allow you to "hook up" > web sites by filling in a <device> on one page with a non-local web > service rather than a physical device. I don't know that it makes much sense for cameras or microphones; I think it's more something that would be suitable for contact lists, calendars, and the like. For cameras, if we wanted to allow people to use Web-provided streams as their outgoing streams, I think we could do that significantly more easily just by using a URL scheme to represent online streams. No need for an entire REST API to be defined for that. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 10 January 2010 06:13:48 UTC