On Mon, Nov 10, 2014 at 8:14 PM, Brendan Eich bren...@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.
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
On Tue, Nov 11, 2014 at 12:28 PM, Robert O'Callahan rob...@ocallahan.org
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
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
On Mon, Nov 10, 2014 at 9:57 AM, Boris Zbarsky bzbar...@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
On Mon, Nov 10, 2014 at 5:33 PM, Brendan Eich bren...@secure.meer.net
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
On Mon, Nov 10, 2014 at 3:14 PM, Domenic Denicola d...@domenic.me 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
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
On Thu, Nov 6, 2014 at 11:02 PM, Mounir Lamouri mou...@lamouri.fr 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
(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
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
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.
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
13 matches
Mail list logo
