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

On Sun, Nov 16, 2014 at 8:30 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:

> On Sun, Nov 16, 2014 at 5:35 PM, Dimitri Glazkov <dglazkov@google.com>
> wrote:
>
>> 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]
>>
>
> 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 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.
>

I don't know if it is. I think I am just asking to give developers a fair
shot at parity. For example, if I am trying to write a RunKeeper a Web app,
I am SOL for some of the more interesting scenarios (tracking heart rate,
pushing data to a smart watch, etc.), and still not quite there with just
plain location tracking while the screen is locked.

As for being experimental vs. fully-baked, I have no expectation that
either health-related platform API will remain the same -- they are both
venturing into a new territory where API shuffling is expected on a routine
basis. So in that way, they are more experimental-smelling than
fully-baked-smelling.

:DG<