On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov <dglaz...@google.com>

> 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

oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
otohoeo ofoioroeo ooofo ohoeololo.

Reply via email to