Re: New approach to activities/intents

On Mon, Nov 10, 2014 at 3:14 PM, Domenic Denicola <d@domenic.me> wrote:

> From: Dimitri Glazkov [mailto:dglazkov@google.com]
>
> >> It's still not clear to me what the advantage is of creating a
> framework for designing proprietary APIs.
> >
> > If we don't do something like this as a platform, we'd be always lagging
> behind. Many new ideas start as proprietary. It takes time for these ideas
> to take shape and travel toward larger acceptance -- or die.
>
> Can you help us understand the advantages of a string-based proprietary
> APIs over a functions-and-objects proprietary APIs? We've had the latter
> for many years with vendor prefixes, so what are the advantages of putting
> them behind navigator.connect?
>

Because that's where the bedrock ends.

I tried to lay it all out in the presentation I gave at the Extensible Web
Summit (
https://docs.google.com/a/glazkov.com/presentation/d/1jqAjoU22R4A4OF6k0Eg0yru2sHz6ehXUffBhOegGEvA/pub?start=false&loop=false&delayms=3000&slide=id.g1df8b027f_015
)

At that point, I was primarily interested in figuring out what would the
lowest-level Web platform API would look like.

If we assume that every JS API is eventually explained, there will still be
some that will require going outside of the web platform. With the Tubes,
every such API eventually bottoms out at a MessagePort. The concept of C++
bindings is literally gone (with a few exceptions -- more on that later).

Since MessagePorts can vend other MessagePorts, you can easily see how the
entire access to the outside could be conceived from one primordial
MessagePort.

I was sort of excited when I stumbled onto this. But then I realized that
this scheme could also be used to explain differences between the
platforms' implementation details, as well as provide extension points.

In the world of Tubes, any API is just sugar around the MessagePorts. So,
when you say functions-and-objects APIs, the Tubes world is viewing it as
some JS that wraps MessagePorts.

It seems reasonable to start without sugar, with just raw ports, let
developers build their own, collect all the patterns, and then come up with
standards around the best patterns. In other words, the responsibility of
sugaring shifts to the userland, and the job of figuring out a good
standard becomes completely data-driven.

There are a few exceptions where Tubes fail. There are synchronous APIs and
APIs that are so performance-sensitive that it would be tough to move them
completely to the Tubes world. But I think that is okay. We can strive for
perfection, but accept squishiness.


> navigator.connect seems great just for talking to foreign service workers
> (in fact it can be the basis for a very general and powerful intents
> system). But from what I can understand it's serving two masters: talking
> to service workers built on standards that run in any browser, and also
> talking to virtual "service workers" that implement proprietary
> string-based APIs using "URLs" that only work in certain browsers. I don't
> understand how these are connected... Hope you can help me out there :)
>

The reason why I see those two as the same thing is because they are only
different in the implementation detail. If I am asking for
http://facebook.com/apis/contacts, I want to get contacts. It shouldn't
matter if they arrive as a result of a SW querying the server or the
Android's contacts provider API.

:DG<