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

Re: New approach to activities/intents

From: Dimitri Glazkov <dglazkov@google.com>
Date: Tue, 11 Nov 2014 09:24:51 -0800
Message-ID: <CADh5Ky31dxk9GOi6w=dD8R4FeB6hiCVkrH=-y9Hmc+Qp_pHRXg@mail.gmail.com>
To: Brendan Eich <brendan@secure.meer.net>
Cc: Domenic Denicola <d@domenic.me>, Anne van Kesteren <annevk@annevk.nl>, Mounir Lamouri <mounir@lamouri.fr>, WebApps WG <public-webapps@w3.org>
On Mon, Nov 10, 2014 at 8:14 PM, Brendan Eich <brendan@secure.meer.net>

> Dimitri Glazkov wrote:
>> Domenic's question still needs addressing separately, but just a quick
>> response here -- the API roc described there is different. Tubes are just
>> like talking to a worker or any MessagePort. There is no extra API surface
>> emerging from getContext-like function call.
> Any getContext or postMessage protocol is inherently not
> object-detectable, at least not at the string-keyed level.
> In principal, as bz said, the tension between extensions and standards
> motivates supporting extensions, and I share your desire to support
> experimentation so long as it is consensus-oriented. We want to avoid
> overlarge jumps by one proprietor, who both risks failing to bring along
> competitors step by step, and seeming to abuse any market power it may
> possess.
> So we want to support extension, extensibility, in ways that don't lead to
> bad game-theoretic and real-world outcomes, e.g. ActiveX PKI in Korea.
> There's no silver bullet or algorithm to do this, but API style matters
> (object detection vs. non-detection; gentle-peoples' agreements about how
> proprietary/particular an API to try).
> The JS SIMD work definitely experiences this tension. Do we want a union
> of all (SSE, NEON, AVX2) vector instructions? Intersection may be too
> small, and emulation may be too slow to be worth using. The
> http://github.com/johnmccutchan/ecmascript_simd issues cover this well,
> and show good particularized thinking.
> To particularize without object detection is hard.
> In any event, IMHO native stacks are not killing the Web, nor are native
> stacks evolving willy-nilly on random and arbitrarily rapid schedules or
> via message-based API settings. Apple and Android are at most annual
> big-release OSes, e.g. I welcome counterexamples.
> Sorry to be skeptical. Object detection, extensible-web-manifesto
> low-level APIs, avoiding indefinitely scoped or "lifetime" proprietary
> extension mechanisms in favor of incrementalism, all seem better to me.
> /be

I would like to reframe this conversation in a slightly more layered
context. Your scepticism is appreciated, but I also would like to make sure
we're on the same page in regard to "the tension" and our collective
understanding of the situation. So, here goes.

I thought about this a bit and realized that we first need to have a common
criteria to evaluate whether we even need something like Tubes. That should
be done before we get into mechanics of the solution. I apologize for
jumping the gun. And I apologize even more to poor op whose conversation we

So I came up with the following Capability Availability Success Criteria:

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

If we're hoping to hit "weeks, not months" and "100%", we need something
like Tubes.

If it's something in between, maybe there are other options.

Setting the bar in terms of these numbers seems like a very charter-ey
thing to decide and agree upon. We should probably do that.

Received on Tuesday, 11 November 2014 17:25:18 UTC

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