On Fri, Jan 8, 2010 at 2:19 PM, Ian Hickson <ian@hixie.ch> wrote: > On Fri, 8 Jan 2010, Adam Barth wrote: > > > > I think Mark's suggestion is to make these APIs webby by giving them > > URLs and letting code interact with them the same way code interacts > > with every other web service. Instead of having these URLs represent > > remote services, they would represent local services. This lets us > > leverage a lot of existing infrastructure, especially in terms of > > privacy and security, and aligns the device APIs with the web > > architecture. > > 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. This presents a pretty big question about how the <device> tag discovers these "virtual" devices in order to allow the user to choose them. However, it would be fine to leave this unspecified for now, until we have had more time to experiment.
Received on Saturday, 9 January 2010 00:27:38 UTC