Re: New approach to activities/intents

[Brendan Eich]

Dimitri Glazkov wrote:
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.


There are definitely other options. I think you've backed yourself into 
a dialectical corner. MessagePorts are not the primitive droids we're 
looking for! For one, JS SIMD cannot and should not use them. Even 
witha  sync-on-this-async-API-call general API, they are not the right 
droid.


I see roc has replied (we are not communicating via back-channels) so 
I'll stop here.


The actor model is beautiful and in part true, but it's not workers or 
MessagePorts, and it's not the right droid. Even if we add actors to the 
web platform, we will need to make particular, non-actor, synchronous 
API additions. These require careful design and (multiple browser) 
implementation with web developer feedback validation. Sorry, no easy 
answers. I do not think we need weeks not months, in any event (as noted 
vs. native stacks). We need intentional design with user (web dev) testing.


/be

Re: New approach to activities/intents

[Dimitri Glazkov]

On Tue, Nov 11, 2014 at 12:28 PM, Robert O'Callahan 
wrote:

> I still don't see how exposing an API via MessagePorts is in any way
> better than exposing an API via WebIDL. Can you describe with concrete
> examples how this makes life better for implementors or authors? I've read
> your presentation but I did not see the answer there.
>
> Furthermore I don't see any necessary connection between MessagePorts vs
> WebIDL and the issues around rapidly bringing experimental APIs to the Web.
> Are you claiming that it's quicker and easier to add MesagePort-based APIs
> to browsers than using WebIDL?
>

I would like to state explicitly that as of
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0376.html, I
withdraw the proposal of Tubes as the exact solution to the problem in lieu
of the need to first formulate a decent problem statement -- in the form of
the criteria I proposed.

:DG<

Re: New approach to activities/intents

[Robert O'Callahan]

I still don't see how exposing an API via MessagePorts is in any way better
than exposing an API via WebIDL. Can you describe with concrete examples
how this makes life better for implementors or authors? I've read your
presentation but I did not see the answer there.

Furthermore I don't see any necessary connection between MessagePorts vs
WebIDL and the issues around rapidly bringing experimental APIs to the Web.
Are you claiming that it's quicker and easier to add MesagePort-based APIs
to browsers than using WebIDL?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 8:14 PM, Brendan Eich 
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<

Re: New approach to activities/intents

[Brendan Eich]

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

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 3:14 PM, Domenic Denicola  wrote:

> From: Dimitri Glazkov [mailto:dglaz...@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<

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 5:33 PM, Brendan Eich 
wrote:

> Right.
>
> Didn't we have a problem with Canvas's string-based getContext already?
>
> http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html


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.

:DG<


>
>
> /be
>
>  Domenic Denicola 
>> November 10, 2014 at 6:14 PM
>> From: Dimitri Glazkov [mailto:dglaz...@google.com]
>>
>>
>> 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?
>>
>> 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 :)
>>
>> Dimitri Glazkov 
>> November 10, 2014 at 12:45 PM
>> On Mon, Nov 10, 2014 at 1:38 AM, Anne van Kesteren > > wrote:
>>
>> On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov
>> mailto:dglaz...@google.com>> wrote:
>> > FWIW, I think we should be concentrating on something like the
>> Tubes (aka
>> > navigator.connect): https://github.com/dglazkov/tubes
>> >
>> > It is hard to impossible to get these types APIs right on the
>> first try.
>> > That's why we need to create a clearinghouse for capability
>> experiments and
>> > be data-driven in designing the right API.
>>
>> 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.  Instead of
>> shunning these ideas until they mature -- and thus effectively shut the
>> door to any innovation, we should embrace them and give them a place in the
>> platform.
>>
>> Take http://www.intel.com/content/www/us/en/architecture-and-
>> technology/realsense-overview.html as an example. It's unclear whether
>> this will lead to anything great. It's even less clear what the Web
>> platform API should look like, or whether this will every result on a
>> standard API. However, if we wait until clarity, we as a platform would
>> lose the ability to participate in the virtuous innovation cycle and, as a
>> result, lose more developer mindshare.
>>
>> 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.
>>
>> :DG<
>>
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>>
>> Anne van Kesteren 
>> November 10, 2014 at 4:38 AM
>>
>> It's still not clear to me what the advantage is of creating a
>> framework for designing proprietary APIs.
>>
>>
>> Dimitri Glazkov 
>> November 7, 2014 at 1:01 PM
>> FWIW, I think we should be concentrating on something like the Tubes (aka
>> navigator.connect): https://github.com/dglazkov/tubes
>>
>> It is hard to impossible to get these types APIs right on the first try.
>> That's why we need to create a clearinghouse for capability experiments and
>> be data-driven in designing the right API.
>>
>> :DG<
>>
>>
>> Mounir Lamouri 
>> November 7, 2014 at 11:57 AM
>>
>> (I realise that my reply went to public-webapps instead of whatwg, not
>> sure why. I will blame my email client :))
>>
>> On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote:
>>
>>> Wouldn't be worth experimenting first with a list of predefined share
 endpoints (that you anyway might want to have) and see if the feature is
 actually something that users are looking for?

>>> We have something like that in Firefox Nightly. Apple ships something
>>> similar in Safari. Both can be extended through proprietary APIs.
>>>
>>
>> I think it would be great if Mozilla could keep track of the usage of
>> this feature and share that data.
>>
>>  Furthermore, wouldn't
 that make sense to have a similar mechanism than Open Search and have a
 way for a website to advertise its share endpoint(s)? Maybe the Mani

Re: New approach to activities/intents

[Brendan Eich]

Right.

Didn't we have a problem with Canvas's string-based getContext already?

http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html

/be


Domenic Denicola 
November 10, 2014 at 6:14 PM
From: Dimitri Glazkov [mailto:dglaz...@google.com]


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?


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 :)


Dimitri Glazkov 
November 10, 2014 at 12:45 PM
On Mon, Nov 10, 2014 at 1:38 AM, Anne van Kesteren > wrote:


On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov
mailto:dglaz...@google.com>> wrote:
> FWIW, I think we should be concentrating on something like the
Tubes (aka
> navigator.connect): https://github.com/dglazkov/tubes
>
> It is hard to impossible to get these types APIs right on the
first try.
> That's why we need to create a clearinghouse for capability
experiments and
> be data-driven in designing the right API.

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.  Instead of shunning these ideas until they mature -- and thus 
effectively shut the door to any innovation, we should embrace them 
and give them a place in the platform.


Take 
http://www.intel.com/content/www/us/en/architecture-and-technology/realsense-overview.html 
as an example. It's unclear whether this will lead to anything great. 
It's even less clear what the Web platform API should look like, or 
whether this will every result on a standard API. However, if we wait 
until clarity, we as a platform would lose the ability to participate 
in the virtuous innovation cycle and, as a result, lose more developer 
mindshare.


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.


:DG<



--
https://annevankesteren.nl/


Anne van Kesteren 
November 10, 2014 at 4:38 AM

It's still not clear to me what the advantage is of creating a
framework for designing proprietary APIs.


Dimitri Glazkov 
November 7, 2014 at 1:01 PM
FWIW, I think we should be concentrating on something like the Tubes 
(aka navigator.connect): https://github.com/dglazkov/tubes


It is hard to impossible to get these types APIs right on the first 
try. That's why we need to create a clearinghouse for capability 
experiments and be data-driven in designing the right API.


:DG<


Mounir Lamouri 
November 7, 2014 at 11:57 AM
(I realise that my reply went to public-webapps instead of whatwg, not
sure why. I will blame my email client :))

On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote:

Wouldn't be worth experimenting first with a list of predefined share
endpoints (that you anyway might want to have) and see if the feature is
actually something that users are looking for?

We have something like that in Firefox Nightly. Apple ships something
similar in Safari. Both can be extended through proprietary APIs.


I think it would be great if Mozilla could keep track of the usage of
this feature and share that data.


Furthermore, wouldn't
that make sense to have a similar mechanism than Open Search and have a
way for a website to advertise its share endpoint(s)? Maybe the Manifest
could be a good use for that. Generally speaking, I see a lot of common
aspects between Open Search and this proposal.

Maybe. It would be even less flexible and depend even more on user
interface innovation from the user agent.


I don't think the issue here is flexibility. It's extensibility. You
want website to be able to advertise themselves in that list. Thus,
websites will only try to do so if they see a benefit in doing that, in
other words, if that feature is actually used by Firefox users.

As a side note, I don't think that innovation always need to come from
new APIs. That feature sounds like

RE: New approach to activities/intents

[Domenic Denicola]

From: Dimitri Glazkov [mailto:dglaz...@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?

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 :)

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 9:57 AM, Boris Zbarsky  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<

Re: New approach to activities/intents

[Boris Zbarsky]

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.


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.


-Boris

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 1:38 AM, Anne van Kesteren  wrote:

> On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov 
> wrote:
> > FWIW, I think we should be concentrating on something like the Tubes (aka
> > navigator.connect): https://github.com/dglazkov/tubes
> >
> > It is hard to impossible to get these types APIs right on the first try.
> > That's why we need to create a clearinghouse for capability experiments
> and
> > be data-driven in designing the right API.
>
> 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.  Instead of
shunning these ideas until they mature -- and thus effectively shut the
door to any innovation, we should embrace them and give them a place in the
platform.

Take
http://www.intel.com/content/www/us/en/architecture-and-technology/realsense-overview.html
as an example. It's unclear whether this will lead to anything great. It's
even less clear what the Web platform API should look like, or whether this
will every result on a standard API. However, if we wait until clarity, we
as a platform would lose the ability to participate in the virtuous
innovation cycle and, as a result, lose more developer mindshare.

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.

:DG<



>
>
> --
> https://annevankesteren.nl/
>

Re: New approach to activities/intents

[Anne van Kesteren]

On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov  wrote:
> FWIW, I think we should be concentrating on something like the Tubes (aka
> navigator.connect): https://github.com/dglazkov/tubes
>
> It is hard to impossible to get these types APIs right on the first try.
> That's why we need to create a clearinghouse for capability experiments and
> be data-driven in designing the right API.

It's still not clear to me what the advantage is of creating a
framework for designing proprietary APIs.


-- 
https://annevankesteren.nl/

Re: New approach to activities/intents

[Dimitri Glazkov]

FWIW, I think we should be concentrating on something like the Tubes (aka
navigator.connect): https://github.com/dglazkov/tubes

It is hard to impossible to get these types APIs right on the first try.
That's why we need to create a clearinghouse for capability experiments and
be data-driven in designing the right API.

:DG<

On Fri, Nov 7, 2014 at 8:57 AM, Mounir Lamouri  wrote:

> (I realise that my reply went to public-webapps instead of whatwg, not
> sure why. I will blame my email client :))
>
> On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote:
> > > Wouldn't be worth experimenting first with a list of predefined share
> > > endpoints (that you anyway might want to have) and see if the feature
> is
> > > actually something that users are looking for?
> >
> > We have something like that in Firefox Nightly. Apple ships something
> > similar in Safari. Both can be extended through proprietary APIs.
>
> I think it would be great if Mozilla could keep track of the usage of
> this feature and share that data.
>
> > > Furthermore, wouldn't
> > > that make sense to have a similar mechanism than Open Search and have a
> > > way for a website to advertise its share endpoint(s)? Maybe the
> Manifest
> > > could be a good use for that. Generally speaking, I see a lot of common
> > > aspects between Open Search and this proposal.
> >
> > Maybe. It would be even less flexible and depend even more on user
> > interface innovation from the user agent.
>
> I don't think the issue here is flexibility. It's extensibility. You
> want website to be able to advertise themselves in that list. Thus,
> websites will only try to do so if they see a benefit in doing that, in
> other words, if that feature is actually used by Firefox users.
>
> As a side note, I don't think that innovation always need to come from
> new APIs. That feature sounds like a great opportunity to innovate
> within the browser UI then iterate with an API.
>
> -- Mounir
>
>

Re: New approach to activities/intents

[Mounir Lamouri]

(I realise that my reply went to public-webapps instead of whatwg, not
sure why. I will blame my email client :))

On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote:
> > Wouldn't be worth experimenting first with a list of predefined share
> > endpoints (that you anyway might want to have) and see if the feature is
> > actually something that users are looking for?
> 
> We have something like that in Firefox Nightly. Apple ships something
> similar in Safari. Both can be extended through proprietary APIs.

I think it would be great if Mozilla could keep track of the usage of
this feature and share that data.

> > Furthermore, wouldn't
> > that make sense to have a similar mechanism than Open Search and have a
> > way for a website to advertise its share endpoint(s)? Maybe the Manifest
> > could be a good use for that. Generally speaking, I see a lot of common
> > aspects between Open Search and this proposal.
> 
> Maybe. It would be even less flexible and depend even more on user
> interface innovation from the user agent.

I don't think the issue here is flexibility. It's extensibility. You
want website to be able to advertise themselves in that list. Thus,
websites will only try to do so if they see a benefit in doing that, in
other words, if that feature is actually used by Firefox users.

As a side note, I don't think that innovation always need to come from
new APIs. That feature sounds like a great opportunity to innovate
within the browser UI then iterate with an API.

-- Mounir

Re: New approach to activities/intents

[Anne van Kesteren]

On Thu, Nov 6, 2014 at 11:02 PM, Mounir Lamouri  wrote:
> My understanding of the document is that a website can register itself
> as a share endpoint but can't try to programmatically starts a share
> action; instead, the user will use the browser UI to do so. Is that
> correct? I assume also that the UA would show a UI requesting the user
> whether they want to accept foo.com to be added as a share endpoint,
> right?

Yes and yes.


> Wouldn't be worth experimenting first with a list of predefined share
> endpoints (that you anyway might want to have) and see if the feature is
> actually something that users are looking for?

We have something like that in Firefox Nightly. Apple ships something
similar in Safari. Both can be extended through proprietary APIs.


> Furthermore, wouldn't
> that make sense to have a similar mechanism than Open Search and have a
> way for a website to advertise its share endpoint(s)? Maybe the Manifest
> could be a good use for that. Generally speaking, I see a lot of common
> aspects between Open Search and this proposal.

Maybe. It would be even less flexible and depend even more on user
interface innovation from the user agent.


-- 
https://annevankesteren.nl/

Re: New approach to activities/intents

[Mounir Lamouri]

On Tue, 4 Nov 2014, at 03:42, Anne van Kesteren wrote:
> A couple of us at Mozilla have been trying to figure out how to revive
> activities/intents for the web. Both work relatively well in closed
> environments such as Firefox OS and Android, but seem harder to deploy
> in a generic way on the web.
> 
> What we've been looking at instead is solving a smaller use case. A
> Sharing API to start and then hopefully reuse the building blocks for
> other features that need to be liberated.
> 
> https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very
> minimal Sharing API could look like.
> 
> Our thinking is that something like the overlay browsing context could
> be reused to make e.g.  or "save as" extensible going
> forward.
> 
> However, admittedly it still doesn't really click. It feels a bit too
> much like e.g. the various search extensions browsers offer. Too much
> work for little return. Furthermore, freeing the web somehow from
> closely knitted silos seems like a worthwhile goal, but is often
> counter to what those silos are interested in. So it might be that
> we're still not quite there yet, thoughts appreciated.

My understanding of the document is that a website can register itself
as a share endpoint but can't try to programmatically starts a share
action; instead, the user will use the browser UI to do so. Is that
correct? I assume also that the UA would show a UI requesting the user
whether they want to accept foo.com to be added as a share endpoint,
right?

Wouldn't be worth experimenting first with a list of predefined share
endpoints (that you anyway might want to have) and see if the feature is
actually something that users are looking for? Furthermore, wouldn't
that make sense to have a similar mechanism than Open Search and have a
way for a website to advertise its share endpoint(s)? Maybe the Manifest
could be a good use for that. Generally speaking, I see a lot of common
aspects between Open Search and this proposal.

-- Mounir

New approach to activities/intents

[Anne van Kesteren]

A couple of us at Mozilla have been trying to figure out how to revive
activities/intents for the web. Both work relatively well in closed
environments such as Firefox OS and Android, but seem harder to deploy
in a generic way on the web.

What we've been looking at instead is solving a smaller use case. A
Sharing API to start and then hopefully reuse the building blocks for
other features that need to be liberated.

https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very
minimal Sharing API could look like.

Our thinking is that something like the overlay browsing context could
be reused to make e.g.  or "save as" extensible going
forward.

However, admittedly it still doesn't really click. It feels a bit too
much like e.g. the various search extensions browsers offer. Too much
work for little return. Furthermore, freeing the web somehow from
closely knitted silos seems like a worthwhile goal, but is often
counter to what those silos are interested in. So it might be that
we're still not quite there yet, thoughts appreciated.

(I put WebApps and TAG on bcc, hope that's okay.)


-- 
https://annevankesteren.nl/