W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2014

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

From: Dimitri Glazkov <dglazkov@google.com>
Date: Tue, 11 Nov 2014 15:36:56 -0800
Message-ID: <CADh5Ky3UXY-2T=mTFOJy412u3MdTzGzaboFaSrz8nx+vzQh=KQ@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Brendan Eich <brendan@secure.meer.net>, Domenic Denicola <d@domenic.me>, Anne van Kesteren <annevk@annevk.nl>, Mounir Lamouri <mounir@lamouri.fr>, WebApps WG <public-webapps@w3.org>
On Tue, Nov 11, 2014 at 3:01 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:

> On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov <dglazkov@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<
Received on Tuesday, 11 November 2014 23:37:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:32 UTC