Re: New approach to activities/intents

On Mon, Nov 10, 2014 at 9:57 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 11/10/14, 12:45 PM, Dimitri Glazkov wrote:
>
>> FWIW, it is perfectly reasonable for us to admit that we as a platform
>> aim to always be years behind other platforms. But then we should make
>> this clear and communicate it to developers who keep trying to not give
>> up on the Web as a viable modern development platform.
>>
>
> Why are developers using the Web as a development platform?
>
> This is a serious question.  The Web has all sorts of warts.  Why are
> people trying to use it?
>
> They're trying to use it because it has several desirable properties other
> platforms lack.  The ones that come to mind for me are ease of deployment
> (e.g. no gatekeepers) and broad availability (having a "modern" web
> browser, for some definition of "modern" is pretty hardware-independent and
> even reasonably OS-independent).  Are there other compelling reasons people
> want to use the web?
>
> Adding a framework for proprietary APIs doesn't affect ease of deployment,
> but it sure does affect broad availability.  That's fine for experiments or
> for people who are willing to restrict their audience (perhaps
> temporarily), as we've seen with early adoption of web features in the
> past.  If we go ahead and create a free-for-all of shipping proprietary
> APIs, though, I think we risk throwing the broad availability baby
> completely out with the bathwater.
>

Agreed that this is a risk and we need to be thoughtful in proceeding
forward with something like Tubes.


>
> There's a tension here, as you point out.  I'm interested in resolving it
> while keeping it clear that proprietary APIs are temporary stopgaps that
> should probably not be relied on for things that are meant to be broadly
> available.  Because a number of web developers don't seem to understand the
> latter; they figure they can just get users to switch to a different UA
> (and operating system, and hardware as needed) to use their site.  And if
> they happen to be a national government, say, they're even right, but that
> doesn't make the result good for the Web. The SSL/crypto story in South
> Korea is the failure mode here.


Agreed on the sadness of the specific story. The interesting part here is
that this scenario is unavoidable in any platform that has a third-party
extensibility story. However, if our only alternative as a platform is to
not offer any extensibility, this is also a failure mode. So we're stuck
picking the lesser of two evils.

In my mind, Tubes is a midpoint between these two extremes. The
message-passing semantics are well-defined, the lifetime expectations are
aligned with the Service Workers.

It might be a good exercise to re-traverse the SEED disaster in different
extremes and trying to find the sweet spot.

For example, I can totally see a government simply building their own
custom build of Chromium or Firefox and requiring its citizens to use it.
The Tubes might help interoperability story only if the said government
published a spec of the protocol. It is highly unlikely that the government
would come to W3C and propose a spec and wait for multiple vendors to
implement it.

:DG<