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

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.


>
>> 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 otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.