Re: Bringing APIs for experimental hardware/software to the Web

+slightlyoff, because he's probably not listening, but should :)

On Wed, Nov 12, 2014 at 8:44 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:

> On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov <dglazkov@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]


>
> 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.


>
> 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).
>

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.
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.

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.


> 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.
>

Yeah, if we go down the path of device drivers, bolting origin on to the
driver will probably need to happen very early in the process.

:DG<