Re: Bringing APIs for experimental hardware/software to the Web
On Sun, Nov 16, 2014 at 8:30 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Nov 16, 2014 at 5:35 PM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Nov 12, 2014 at 8:44 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov dglaz...@google.com wrote: Nevertheless, I am optimistic. I would like to have this discussion and hear your ideas. OK. The following ideas are somewhat half-baked so don't judge me too harshly :-). Rapid deployment of experimental APIs in the browser clashes with our existing goals. It takes time to negotiate APIs, to create multiple interoperable implementations, to validate safety, etc. So I conclude we shouldn't bake them into the browser. Instead we could achieve most of our goals by enabling third parties to deploy experimental functionality in browser-independent, device-independent packages that can be used by --- and if necessary shipped alongside --- Web applications. To the extent we can do that, we make an end-run around the standardization problem. This implies that we need to first design/specify an environment (execution/packaging/etc.) for this. Right? This seems like a massive investment of time. Not saying it's a bad idea. Unless you have a piano neatly stashed away in the bushes waiting for me to ask this question :) [ http://en.wikipedia.org/wiki/Grigori_Gorin] This need not be a hard problem, depending on other decisions we make. It might be as simple as load an IFRAME with a well-known URL at some vendor's Web site and exchange postMessages with it, or load a script directly from the vendor's Web site (which might do the IFRAME/postmessage thing under the hood and vend a friendlier API). We may not need to standardize anything specific here, although it would be good to have some best practices to recommend. Okay. That lines up well with my thinking on the Tubes proposal. For software, this means we need a browser-based execution environment that can run the code that implements these APIs. I think for C/C++ code, we're nearly there already. For GPU code the situation is murkier and we need to solve it (but we already need to). Agreed. Somewhat tangentially, would like to know your opinion on the bedrock and extensible manifesto thing. It seems that primitive archeology presupposes that C/C++ is ultimately brushed down to nothing. I don't understand what you're saying here. If you look at https://extensiblewebmanifesto.org/ and project the path forward with those guidelines in mind, at some point, you will hit the bedrock -- a set of platform APIs that can no longer be explained in terms of other, more low-level APIs. Given that, what is beneath this bedrock? To what degree will we succeed with JS as a platform host language? Will there remain things like C++ bindings and the exotic objects that they bring along? Okay. I think I understand this part. Since USB is basically the common bus for new hardware innovation anyway, we could just go down to USB and build up from there. I have a couple of concerns: 1) This means you'll effectively have to implement device drivers twice -- once for host OS, once for Web platform. That seems like doubling the work and lessening the chance of the developer actually going through it. We ought to be able to provide glue code to ease porting, e.g. by emulating libusb or the Android USB interface on top of whatever Web USB API we provide. Sounds like there's some prior art in this space: https://developer.chrome.com/apps/app_usb and https://wiki.mozilla.org/WebAPI/WebUSB. Interesting bit about caveats: https://developer.chrome.com/apps/app_usb#caveats I immediately feel ill-informed to determine whether exposing a USB API satisfies most developer/vendor needs. Sounds like a bug for me to fix ;) 2) Instilling a device-independent device driver culture seems like a tough challenge. Two device vendors need to have an incentive to collaborate on a driver that works for both of their nearly identical crazy camera tricks. The slope here is not going to be leaning in our favor. There seems to be a misunderstanding. In this context, I explicitly abandon the goal of having a single driver or API for diverse hardware. Okay. Makes sense. It might be good to start enumerating the types of APIs we're interested in. For example, we could take Apple's HealthKit ( https://developer.apple.com/healthkit/) and Google's Fit ( https://developers.google.com/fit/overview) as some of the things developers might need, and see how we could deliver them. One key result I am looking for here is adapting to fit into existing frameworks like that, rather than building our own. Though rebuilding both of the things from scratch for the Web platform -- however NIH -- should still be on the table. These frameworks do not fit very well into the scope of my problem statement; I don't see them as
Re: Bringing APIs for experimental hardware/software to the Web
On Sun, Nov 16, 2014 at 5:35 PM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Nov 12, 2014 at 8:44 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov dglaz...@google.com wrote: Nevertheless, I am optimistic. I would like to have this discussion and hear your ideas. OK. The following ideas are somewhat half-baked so don't judge me too harshly :-). Rapid deployment of experimental APIs in the browser clashes with our existing goals. It takes time to negotiate APIs, to create multiple interoperable implementations, to validate safety, etc. So I conclude we shouldn't bake them into the browser. Instead we could achieve most of our goals by enabling third parties to deploy experimental functionality in browser-independent, device-independent packages that can be used by --- and if necessary shipped alongside --- Web applications. To the extent we can do that, we make an end-run around the standardization problem. This implies that we need to first design/specify an environment (execution/packaging/etc.) for this. Right? This seems like a massive investment of time. Not saying it's a bad idea. Unless you have a piano neatly stashed away in the bushes waiting for me to ask this question :) [ http://en.wikipedia.org/wiki/Grigori_Gorin] This need not be a hard problem, depending on other decisions we make. It might be as simple as load an IFRAME with a well-known URL at some vendor's Web site and exchange postMessages with it, or load a script directly from the vendor's Web site (which might do the IFRAME/postmessage thing under the hood and vend a friendlier API). We may not need to standardize anything specific here, although it would be good to have some best practices to recommend. For software, this means we need a browser-based execution environment that can run the code that implements these APIs. I think for C/C++ code, we're nearly there already. For GPU code the situation is murkier and we need to solve it (but we already need to). Agreed. Somewhat tangentially, would like to know your opinion on the bedrock and extensible manifesto thing. It seems that primitive archeology presupposes that C/C++ is ultimately brushed down to nothing. I don't understand what you're saying here. Okay. I think I understand this part. Since USB is basically the common bus for new hardware innovation anyway, we could just go down to USB and build up from there. I have a couple of concerns: 1) This means you'll effectively have to implement device drivers twice -- once for host OS, once for Web platform. That seems like doubling the work and lessening the chance of the developer actually going through it. We ought to be able to provide glue code to ease porting, e.g. by emulating libusb or the Android USB interface on top of whatever Web USB API we provide. 2) Instilling a device-independent device driver culture seems like a tough challenge. Two device vendors need to have an incentive to collaborate on a driver that works for both of their nearly identical crazy camera tricks. The slope here is not going to be leaning in our favor. There seems to be a misunderstanding. In this context, I explicitly abandon the goal of having a single driver or API for diverse hardware. It might be good to start enumerating the types of APIs we're interested in. For example, we could take Apple's HealthKit ( https://developer.apple.com/healthkit/) and Google's Fit ( https://developers.google.com/fit/overview) as some of the things developers might need, and see how we could deliver them. One key result I am looking for here is adapting to fit into existing frameworks like that, rather than building our own. Though rebuilding both of the things from scratch for the Web platform -- however NIH -- should still be on the table. These frameworks do not fit very well into the scope of my problem statement; I don't see them as experimental, but rather fully-baked platform APIs with hardware abstraction and long-term support guarantees. We could try to apply my proposal to them, by treating the entire framework (and in particular the shared data store) as a kind of device. The low level I/O API would then be some kind of standardized bridge between JS and Objective-C or Java, with JS-API-vending wrapper scripts hosted by the OS vendor (or possibly the device OEM, in the Android case). This would of course facilitate wholesale exposure of native platform APIs to the Web. That sounds a lot more dangerous than just exposing USB --- but for these frameworks, that's essentially what you're asking for. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo
Re: Bringing APIs for experimental hardware/software to the Web
On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov dglaz...@google.com wrote: Nevertheless, I am optimistic. I would like to have this discussion and hear your ideas. OK. The following ideas are somewhat half-baked so don't judge me too harshly :-). Rapid deployment of experimental APIs in the browser clashes with our existing goals. It takes time to negotiate APIs, to create multiple interoperable implementations, to validate safety, etc. So I conclude we shouldn't bake them into the browser. Instead we could achieve most of our goals by enabling third parties to deploy experimental functionality in browser-independent, device-independent packages that can be used by --- and if necessary shipped alongside --- Web applications. To the extent we can do that, we make an end-run around the standardization problem. For software, this means we need a browser-based execution environment that can run the code that implements these APIs. I think for C/C++ code, we're nearly there already. For GPU code the situation is murkier and we need to solve it (but we already need to). Hardware is more challenging. I think here it makes sense to have low-level Web APIs for I/O, e.g. USB. So, when someone produces a sensor/actuator USB gadget with accompanying software, we should be able to compile the software for Web use, wrap an API around it that Web apps can use, and host it in any browser. This hits most of our goals: as long as the package remains available, there's compatibility; it's device-independent apart from the dependency on the specific gadget; and it works across browsers (though there's only one implementation of that specific component). Safety is a big concern with low-level hardware access. An obvious path would be to require some kind of trust decision for apps depending (indirectly) on privileged hardware access, but maybe there's a better way. For example, when you attach a USB device you're implicitly trusting the vendor already. What if the browser could extract a vendor domain name from the device (e.g. via a trusted registry) and granted I/O access to that device for packages loaded from that domain? A package could claim it provides a sanitized API to apps, freeing those apps from the trust decision requirement. When, inevitably, something goes wrong, either the package is patched or the browser is updated to stop trusting the package. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Bringing APIs for experimental hardware/software to the Web
On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov dglaz...@google.com wrote: Given any capability on a modern computing device and a developer who wants to use it, what is a) the acceptable delay between when this capability becomes available on the web platform vs. first being available on a native platform, and b) the likelihood that this capability will ever be available on the web platform. If we're aiming at years, not months, and 60-80%, then we're already successful. If we're hoping to hit weeks, not months and 100%, we need something like Tubes. I don't think we should set targets for a) and b) and hit those targets no matter what the cost. We need to do the hard work of evaluating tradeoffs case by case. I assume everyone agrees that when there are no hard tradeoffs to make, of course we'd like to have nice things. We can have a productive discussion about how to bring APIs for experimental hardware and software to the Web faster. Subject changed to suit. Here's my problem statement: We have a set of traditional goals for the Web platform: backward compatibility, device independence, multiple interoperable implementations, long-term durability, coherence, ease of use, safety, etc. People frequently release new hardware and software with new capabilities that don't fit into existing Web APIs. Can we expose these capabilities to Web developers with very low delay, without violating some of our existing goals? If we can't, what tradeoffs are we willing to make? If this is the discussion you want to have, then I will reveal some ideas :-). Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Re: Bringing APIs for experimental hardware/software to the Web
On Tue, Nov 11, 2014 at 3:01 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov dglaz...@google.com wrote: Given any capability on a modern computing device and a developer who wants to use it, what is a) the acceptable delay between when this capability becomes available on the web platform vs. first being available on a native platform, and b) the likelihood that this capability will ever be available on the web platform. If we're aiming at years, not months, and 60-80%, then we're already successful. If we're hoping to hit weeks, not months and 100%, we need something like Tubes. I don't think we should set targets for a) and b) and hit those targets no matter what the cost. We need to do the hard work of evaluating tradeoffs case by case. I assume everyone agrees that when there are no hard tradeoffs to make, of course we'd like to have nice things. We can have a productive discussion about how to bring APIs for experimental hardware and software to the Web faster. Subject changed to suit. Here's my problem statement: We have a set of traditional goals for the Web platform: backward compatibility, device independence, multiple interoperable implementations, long-term durability, coherence, ease of use, safety, etc. People frequently release new hardware and software with new capabilities that don't fit into existing Web APIs. Can we expose these capabilities to Web developers with very low delay, without violating some of our existing goals? If we can't, what tradeoffs are we willing to make? If this is the discussion you want to have, then I will reveal some ideas :-). I think that's a reasonable problem statement. There are two problems with it: 1) it makes an assumption that everyone on this forum wants very low delay and all capabilities. I don't know if that is true, though I definitely want to believe it. 2) it's not as focused as my formulation on actually setting a target for ourselves, which makes me worried we'll end up in the same loosely incoherent state we always end up. Nevertheless, I am optimistic. I would like to have this discussion and hear your ideas. :DG
