Re: New approach to activities/intents

On Mon, Nov 10, 2014 at 8:14 PM, Brendan Eich <brendan@secure.meer.net>
wrote:

> 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
hijacked.

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
successful.

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.

:DG<