Re: Sync API for workers

> > > Look at IndexedDB API, since asynchronous one was enought dfor everybody, > synchronous one was not implemented by the browsers and now it has became > deprecated... :-) > > Well regarding my position I would not smile ;-) > I was considering a server-side implementation of indexedDB. There

Re: Sync API for workers

Could we change the method name under discussion to `postMessageSync` instead of `postSyncMessage`? I know they're not grammatically equivalent but I've always found the *Sync suffixes used on pertinent Node.js APIs to be much more intuitive than trying to guess which position within a string of wo

Re: Sync API for workers

This meant to be a more limited and well-behaved variant. However, as pointed out by Jonas, a very similar proposal has been submitted and discussed long before I joined this list. So, please disregard my proposal, it is an artifact of me not searching the archives well enough. Best regards, Davi

Re: Sync API for workers

You snipped the comment about waitForMessage(). I think it should return an Event, as if the message had been received from onmessage, not just the received data. On Sun, Oct 13, 2013 at 10:37 PM, Jonas Sicking wrote: > This is certainly an improvement over the previous proposal. However > give

Re: Sync API for workers

On Mon, Oct 14, 2013 at 2:33 AM, David Rajchenbach-Teller wrote: > Let me introduce the first sketch of a variant. The general idea is to > add a |postSyncMessage| > > We extend DedicatedWorkerGlobalScope and MessageEvent as follows: > > interface DedicatedWorkerGlobalScope : WorkerGlobalScope { >

Re: Sync API for workers

- Original Message - > From: "David Bruant" > To: "Jonas Sicking" > Cc: "public-webapps" , aza...@mozilla.com > Sent: Sunday, October 13, 2013 1:36:22 PM > Subject: Re: Sync API for workers > > > * You could solve the use case o

Re: Sync API for workers

On 10/13/13 4:21 PM, James Greene wrote: >> a) is necessary, but for b) it is sufficient for the sync thread to be >> able to sleep until a condition/mutex/... is lifted > > In other words, your clarification is completely true but my initial > statement was written with regard to client-side Java

Re: Sync API for workers

Let me introduce the first sketch of a variant. The general idea is to add a |postSyncMessage| We extend DedicatedWorkerGlobalScope and MessageEvent as follows: interface DedicatedWorkerGlobalScope : WorkerGlobalScope { void postMessage(any message, optional sequence transfer); any postSyncMe

Re: Sync API for workers

On Sun, Oct 13, 2013 at 8:19 PM, Glenn Maynard wrote: > On Sun, Oct 13, 2013 at 8:11 PM, Glenn Maynard wrote: >> >> - Descendants of a MessagePortSyncSide's initial thread are always legal >> threads. Additionally, if the port's transferred first value is true, the >> initial thread itself is al

Re: Sync API for workers

On Sun, Oct 13, 2013 at 8:11 PM, Glenn Maynard wrote: > - Descendants of a MessagePortSyncSide's initial thread are always legal > threads. Additionally, if the port's transferred first value is true, the > initial thread itself is also a legal thread. > - Ancestors of a MessagePortSyncSide's in

Re: Sync API for workers

What I really dislike about this is that the worker can't send the port directly to a UI thread if it's a nested worker; it has to send it to its parent, who has to forward it to its parent, and so on. That seems like it'll make it hard to implement libraries, since libraries needs to have its fin

Re: Sync API for workers

Rick: Thanks for confirming that. Being more familiar with generators (and other ES6 goodies), can you envision any setup where a generator (or perhaps multiple yielding to each other) would enable us to build synchronous API wrappers around async APIs in JS? On Oct 13, 2013 6:44 PM, "Rick Waldron

Re: Sync API for workers

On Sunday, October 13, 2013, James Greene wrote: > Oh, does `yield` work anywhere? I thought it was only for use within > generators. Admittedly, I haven't been keeping up with the latest ES6 > changes. > yield may only appear in the body of a generator function, denoted by star syntax: function*

Re: Sync API for workers

On Sun, Oct 13, 2013 at 1:36 PM, David Bruant wrote: > Le 13/10/2013 21:39, Jonas Sicking a écrit : > >> Ok, this thread is clearly heading off the deep end. Let me clear up a >> few points of confusion: >> >> * You can not wrap a truly synchronous library around an asynchronous >> API. Spinning t

Re: Sync API for workers

Le 13/10/2013 21:39, Jonas Sicking a écrit : Ok, this thread is clearly heading off the deep end. Let me clear up a few points of confusion: * You can not wrap a truly synchronous library around an asynchronous API. Spinning the event loop gets you close, but breaks run-to-completion. Furthermor

Re: Sync API for workers

Ok, this thread is clearly heading off the deep end. Let me clear up a few points of confusion: * You can not wrap a truly synchronous library around an asynchronous API. Spinning the event loop gets you close, but breaks run-to-completion. Furthermore, spinning the event loop is irrelevant as we

Re: Sync API for workers

Demostration by example, thanks :-) 2013/10/13 David Rajchenbach-Teller : > On 10/13/13 6:33 PM, pira...@gmail.com wrote: >> Don't know, I only know behavior of Python yield statement, but >> Javascript one was developed following it and I'm 90% secure it follows >> the same behaviour (almost all

Re: Sync API for workers

On 10/13/13 6:33 PM, pira...@gmail.com wrote: > Don't know, I only know behavior of Python yield statement, but > Javascript one was developed following it and I'm 90% secure it follows > the same behaviour (almost all new functionalities of Javascript are > being borrowed from Python since seems M

Re: Sync API for workers

Don't know, I only know behavior of Python yield statement, but Javascript one was developed following it and I'm 90% secure it follows the same behaviour (almost all new functionalities of Javascript are being borrowed from Python since seems Mozilla Javascript implementors are Python ex-programme

Re: Sync API for workers

Oh, does `yield` work anywhere? I thought it was only for use within generators. Admittedly, I haven't been keeping up with the latest ES6 changes. On Oct 13, 2013 9:38 AM, "pira...@gmail.com" wrote: > Javascript now has support for yield statements the same way Python does, > that's a way to sto

Re: Sync API for workers

Javascript now has support for yield statements the same way Python does, that's a way to stop (ie. sleep) the execution of a script to allow another to work and restart from there. It's not their main function, but allow to create what's called "greenlets", green threads, and that's how I seen syn

Re: Sync API for workers

> a) is necessary, but for b) it is sufficient for the sync thread to be > able to sleep until a condition/mutex/... is lifted In other words, your clarification is completely true but my initial statement was written with regard to client-side JavaScript, which cannot sleep. As such, I believe my

Re: Sync API for workers

Actually only IDBRequest need to be sync, which are prone to error and complicate workflow. Async workflow on database opening and transaction request are fine. Kyaw

Re: Sync API for workers

Thanks for adding clarification. That CAN be true but it depends on the environment [so far as I can see]. For example, such an API wrapper couldn't be built in today's client-side JavaScript because the UI thread can't do a synchronous yielding "sleep" but rather can only do a synchronous blockin

Re: Sync API for workers

On 10/12/13 3:48 PM, James Greene wrote: > You can only build a synchronous API on top of an asynchronous API if > they are (a) running in separate threads/processes AND (b) the sync > thread can synchronously poll (busy loop) for the progress/completion of > the async thread. a) is necessary, but

Re: Sync API for workers

You can only build a synchronous API on top of an asynchronous API if they are (a) running in separate threads/processes AND (b) the sync thread can synchronously poll (busy loop) for the progress/completion of the async thread. On Oct 12, 2013 1:23 AM, "pira...@gmail.com" wrote: > >> Synchronous

Re: Sync API for workers

>> Synchronous APIs are easier to use since it's how things have been done since decades ago, > > > No, they're easier to use because they fit the model of linear human thought more naturally. The idea that asynchronous APIs are just as good and easy as synchronous APIs, and that people only disag

Re: Sync API for workers

> When I see discussion of any new/recent synchronous APIs for the Web > platform these days I pretty much take it they're implicitly intended just > for use with Workers. So I assume that's the context Jonas intended. > It's a safe assumption, but I think it's better to be asynchronous also on wor

Re: Sync API for workers

On Fri, Oct 11, 2013 at 2:24 PM, pira...@gmail.com wrote: > Synchronous APIs are easier to use since it's how things have been done > since decades ago, > No, they're easier to use because they fit the model of linear human thought more naturally. The idea that asynchronous APIs are just as good

Re: Sync API for workers

"pira...@gmail.com" , 2013-10-11 21:24 +0200: > [Jonas said]: > > * Enable compiling code that was written for other platforms to the > > web. Specifically where such code uses synchronous APIs, but where we > > for good reasons have chosen not to expose synchronous counterparts in > > the web pla

Re: Sync API for workers

> * Enable compiling code that was written for other platforms to the > web. Specifically where such code uses synchronous APIs, but where we > for good reasons have chosen not to expose synchronous counterparts in > the web platform. The most obvious example here is synchronous > filesystem access

Re: Sync API for workers

On Wed, Sep 5, 2012 at 7:03 PM, Jonas Sicking wrote: > Hence I think something like the following would work: > > [Constructor] > interface SyncMessageChannel { > readonly attribute MessagePortSyncSide syncPort; > readonly attribute MessagePortAsyncSide asyncPort; > }; > > interface MessagePor

Re: Sync API for workers

> On Thu, Sep 6, 2012 at 7:18 PM, Glenn Maynard wrote: >> On Thu, Sep 6, 2012 at 12:31 AM, Jonas Sicking wrote: >> That is certainly an interesting use case. I think another interesting >> use case is being able to write synchronous APIs in workers whose >> implementation uses APIs that are only

Re: Sync API for workers

Just to ping a detail, so it's not lost in history: it should also be possible to peek at a On Thu, Sep 6, 2012 at 12:31 AM, Jonas Sicking wrote: > > 1: allow blocking upwards, 2: allow blocking downwards, > > Indeed. But I believe #2 is more useful than #1. I wasn't proposing > having both, I w

Re: Sync API for workers

On 09/06/2012 05:03 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 12:49 AM, Jonas Sicking wrote: Importantly, the sending side doesn't have to know whether the receiving side is using a sync API to receive it or not--in other words, that information doesn't have to be part of the user's messa

Re: Sync API for workers

On Wed, Sep 5, 2012 at 11:56 PM, Olli Pettay wrote: > On 09/06/2012 09:49 AM, Jonas Sicking wrote: >> >> On Wed, Sep 5, 2012 at 11:30 PM, Olli Pettay >> wrote: >>> >>> On 09/06/2012 09:12 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi wrote: > > >

Re: Sync API for workers

On 09/06/2012 09:49 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 11:30 PM, Olli Pettay wrote: On 09/06/2012 09:12 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi wrote: On 09/06/2012 08:31 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard

Re: Sync API for workers

On Wed, Sep 5, 2012 at 11:30 PM, Olli Pettay wrote: > On 09/06/2012 09:12 AM, Jonas Sicking wrote: >> >> On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi wrote: >>> >>> On 09/06/2012 08:31 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard wrote: > > >>>

Re: Sync API for workers

On 09/06/2012 09:30 AM, Olli Pettay wrote: On 09/06/2012 09:12 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi wrote: On 09/06/2012 08:31 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard wrote: On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking w

Re: Sync API for workers

On 09/06/2012 09:12 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi wrote: On 09/06/2012 08:31 AM, Jonas Sicking wrote: On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard wrote: On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking wrote: The problem with a "Only allow bloc

Re: Sync API for workers

On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi wrote: > On 09/06/2012 08:31 AM, Jonas Sicking wrote: >> >> On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard wrote: >>> >>> On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking wrote: The problem with a "Only allow blocking on children, except

Re: Sync API for workers

On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard wrote: > On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking wrote: >> >> The problem with a "Only allow blocking on children, except that >> window can't block on its children" is that you can never block on a >> computation which is implemented in the mai

Re: Sync API for workers

On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking wrote: > The problem with a "Only allow blocking on children, except that > window can't block on its children" is that you can never block on a > computation which is implemented in the main thread. I think that cuts > out some major use cases since

Re: Sync API for workers

On Wed, Sep 5, 2012 at 7:03 PM, Jonas Sicking wrote: > [Constructor] > interface MessageChannel { > readonly attribute MessagePortSyncSide syncPort; > readonly attribute MessagePortAsyncSide asyncPort; > }; This should of course say SyncMessageChannel. / Jonas

Re: Sync API for workers

On Wed, Sep 5, 2012 at 12:49 AM, Jonas Sicking wrote: >> Importantly, the sending side >> doesn't have to know whether the receiving side is using a sync API to >> receive it or not--in other words, that information doesn't have to be part >> of the user's messaging protocol. > > I agree that this

Re: Sync API for workers

On Mon, Sep 3, 2012 at 8:55 PM, Glenn Maynard wrote: > On Mon, Sep 3, 2012 at 9:30 PM, Jonas Sicking wrote: >> >> We can't generically block on children since we can't let the main >> window block on a child. That would effectively permit synchronous IO >> from the main thread which is not someth

Re: Sync API for workers

On Tue, Sep 4, 2012 at 1:59 PM, Brendan Eich wrote: > David Bruant wrote: >> >> I can imagine, it sounds hard indeed. Do you have numbers on how it >> affects performance? Or an intuition on these numbers? I don't need to >> be convinced that it affects performance significantly, but just to get >

Re: Sync API for workers

On Sat, Sep 1, 2012 at 11:49 AM, David Bruant wrote: > Also, I don't think I have seen mentionned use cases of things that are > not possible without a Sync API. Everything presented is already > possible (sometimes at arguably high costs like Glenn Maynard's use case > in discussion [1]). I have

Re: Sync API for workers

On Mon, Sep 3, 2012 at 10:55 PM, Glenn Maynard wrote: > I suspect there's a way to make the general-case version work, though. > To restate this by itself instead of as a delta: - Add an internal flag to MessagePort, "blocking permitted", which is initially set. Add a value "previous owner", w

Re: Sync API for workers

On Tue, Sep 4, 2012 at 3:11 PM, Ian Hickson wrote: > On Mon, 3 Sep 2012, Glenn Maynard wrote: > > > > - Add an internal flag to MessagePort, "blocking permitted", which is > > initially set. > > - When a MessagePort "port" is transferred from source to dest, > > - If source is an ancestor of

Re: Sync API for workers

David Bruant wrote: I can imagine, it sounds hard indeed. Do you have numbers on how it affects performance? Or an intuition on these numbers? I don't need to be convinced that it affects performance significantly, but just to get an idea. This is not going to be easy to estimate, but you might

Re: Sync API for workers

Alon Zakai wrote: Technically it might be possible to automatically rewrite such code to use asynchronous coding patterns, but so far I don't think anyone has managed to do that. >>> Naively, I would say, that once we've paid the price to compile code >>> from one language t

Re: Sync API for workers

[Forwarding a response from Alon Zakai, who is behind Emscripten and CC'ing him] >>> There is also another use-case which has been brought up. As the >>> web >>> platform is becoming more powerful, people have started converting >>> code written for other platforms to javascript+html. >> By "ht

Re: Sync API for workers

On Mon, 3 Sep 2012, Glenn Maynard wrote: > > - Add an internal flag to MessagePort, "blocking permitted", which is > initially set. > - When a MessagePort "port" is transferred from source to dest, > - If source is an ancestor of dest, the "blocking permitted" flag of > "port" is cleared. (Th

Re: Sync API for workers

On Tue, Sep 4, 2012 at 2:23 PM, David Bruant wrote: > Tooling isn't perfect for async debugging. It's being worked on. Yet it > hasn't prevented web devs from buiding (and debugging) event-based code. > Developers work in lots of bad environments and get stuff done anyway. That's no argument. A

Re: Sync API for workers

Le 04/09/2012 20:47, Glenn Maynard a écrit : > On Tue, Sep 4, 2012 at 12:49 PM, David Bruant > wrote: > > I'm sorry, but I have to disagree. Have you ever used promises in > a large-scale project? > I've been amazed to discover that promise-based API are >

Re: Sync API for workers

On Tue, Sep 4, 2012 at 12:49 PM, David Bruant wrote: > I'm sorry, but I have to disagree. Have you ever used promises in a > large-scale project? > I've been amazed to discover that promise-based API are ridiculously much > easier to refactor than callback-based API. Obviously, refactoring > nece

Re: Sync API for workers

Le 04/09/2012 18:46, Glenn Maynard a écrit : > On Tue, Sep 4, 2012 at 10:32 AM, David Bruant > wrote: > > Cognitive load is the only one mentioned so far. It is a serious > issue since for the foreseeable future, only human beings will be > writing code. > >

Re: Sync API for workers

On Tue, Sep 4, 2012 at 10:32 AM, David Bruant wrote: > Cognitive load is the only one mentioned so far. It is a serious issue > since for the foreseeable future, only human beings will be writing code. > However, as said, there are solutions to reduce this load. > I wish to share an experience. >

Re: Sync API for workers

Le 04/09/2012 17:03, Glenn Maynard a écrit : On Tue, Sep 4, 2012 at 4:23 AM, David Bruant > wrote: The proposed solution here throws away all benefits of async code to reduce the complexity of writing async code by... writing sync code. I wish we'd exp

Re: Sync API for workers

On Tue, Sep 4, 2012 at 4:23 AM, David Bruant wrote: > The proposed solution here throws away all benefits of async code to > reduce the complexity of writing async code by... writing sync code. > > I wish we'd explore more solutions to make async more workable rather than > throwing away async. >

Re: Sync API for workers

On 9/4/12 8:54 AM, David Bruant wrote: Ok I wasn't aware of that. Do you have bug numbers in mind by any chance? I don't offhand, unfortunately. Would have to search. -Boris

Re: Sync API for workers

Le 04/09/2012 14:34, Boris Zbarsky a écrit : On 9/4/12 5:23 AM, David Bruant wrote: Also, I wish the demand came from the people who do work on Emscripten or Mandreel As far as I know, what Jonas is saying about Emscripten did come from the Emscripten folks. I've certainly seen them say it i

Re: Sync API for workers

On 9/4/12 5:23 AM, David Bruant wrote: Also, I wish the demand came from the people who do work on Emscripten or Mandreel As far as I know, what Jonas is saying about Emscripten did come from the Emscripten folks. I've certainly seen them say it in bugs in the recent past. No guessing invol

Re: Sync API for workers

Hi, Before anything else, thanks for this detailed and quite complete explanation. Le 03/09/2012 23:32, Jonas Sicking a écrit : The other thing that I wanted to talk about is use cases. It has been claimed in this thread that synchronous message passing isn't needed and that people can just w

Re: Sync API for workers

On Mon, Sep 3, 2012 at 9:30 PM, Jonas Sicking wrote: > We can't generically block on children since we can't let the main > window block on a child. That would effectively permit synchronous IO > from the main thread which is not something that we want to allow. > The UI thread would never be al

Re: Sync API for workers

On Mon, Sep 3, 2012 at 4:47 PM, Glenn Maynard wrote: > On Mon, Sep 3, 2012 at 4:32 PM, Jonas Sicking wrote: >> >> It seems hard to ensure that deadlocks can't happen if we try to allow >> blocking calls on generic MessagePorts, this is why we haven't been >> interested in doing that. I'm not sayi

Re: Sync API for workers

On Mon, Sep 3, 2012 at 4:32 PM, Jonas Sicking wrote: > It seems hard to ensure that deadlocks can't happen if we try to allow > blocking calls on generic MessagePorts, this is why we haven't been > interested in doing that. I'm not saying it's impossible, but if > someone wants to propose this, p

Re: Sync API for workers

Hi All, I'd like to start by clearing up some confusion here. That's why I'm responding to the first email in this thread. We at mozilla have no interest in creating an API which runs the risk of causing dead-locks. I would expect this to be true of other browser vendors too, though obviously I c

Re: Sync API for workers

On Sun, Sep 2, 2012 at 12:16 PM, Glenn Maynard wrote: > On Sun, Sep 2, 2012 at 12:24 PM, Andrew Wilson wrote: > >> I am not optimistic that we can do deadlock prevention in the general >> case with MessagePorts, for the same reason that it's prohibitively >> difficult to reliably garbage collect

Re: Sync API for workers

On Sun, 2 Sep 2012, Andrew Wilson wrote: > > Just wanted to point out that all of the arguments for a wait-for-reply API > in workers also apply to SharedWorkers. It's trickier for SharedWorkers > since they use MessagePorts Dedicated Workers use MessagePorts too, they're just embedded in the Wo

Re: Sync API for workers

On Sun, Sep 2, 2012 at 12:24 PM, Andrew Wilson wrote: > Just wanted to point out that all of the arguments for a wait-for-reply > API in workers also apply to SharedWorkers. It's trickier for SharedWorkers > since they use MessagePorts, and we probably don't want to expose this kind > of API to p

Re: Sync API for workers

On Sat, Sep 1, 2012 at 2:32 PM, Glenn Maynard wrote: > On Sat, Sep 1, 2012 at 3:19 PM, Rick Waldron wrote: > >> I can seriously dispute this, as someone who involved in research and >> development of JavaScript programming for hardware. Processing high volume >> serialport IO is relatively simple

Re: Sync API for workers

On Sat, Sep 1, 2012 at 3:19 PM, Rick Waldron wrote: > I can seriously dispute this, as someone who involved in research and > development of JavaScript programming for hardware. Processing high volume > serialport IO is relatively simple with streams and data events. It's just > a matter of think

Re: Sync API for workers

On Sat, Sep 1, 2012 at 5:12 PM, Olli Pettay wrote: > On 09/01/2012 11:38 PM, Rick Waldron wrote: > > So far, they all look async. Just calling them "sync" doesn't make them >> "sync". >> > > Sure they are sync. They are sync inside worker. We all know that we must > not introduce > new sync APIs

Re: Sync API for workers

Le 01/09/2012 22:30, Rick Waldron a écrit : > On Saturday, September 1, 2012 at 4:02 PM, Glenn Maynard wrote: >> On Sat, Sep 1, 2012 at 11:49 AM, David Bruant > > wrote: >>> # Discussion 2 >>> ## Joshua Bell [5] >>> "This can be done today using bidirectional postMessage,

Re: Sync API for workers

On 09/01/2012 11:38 PM, Rick Waldron wrote: So far, they all look async. Just calling them "sync" doesn't make them "sync". Sure they are sync. They are sync inside worker. We all know that we must not introduce new sync APIs in the main thread.

Re: Sync API for workers

t; > On 09/01/2012 11:19 PM, Rick Waldron wrote: > > > David, > > Thanks for preparing this summary—I just wanted to note that I still stand > behind my original, reality based arguments. > > One comment inline.. > > On Saturday, September 1, 2012 at 12:49 PM,

Re: Sync API for workers

s for preparing this summary—I just wanted to note that I still stand >>> behind my original, reality based arguments. >>> >>> One comment inline.. >>> >>> On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote: >>> >>>> H

Re: Sync API for workers

nts. > > > > One comment inline.. > > > > On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote: > > > > > Hi, > > > > > > A Sync API for workers is being implemented in Firefox [1]. > > > I'd like to come back to

Re: Sync API for workers

On Saturday, September 1, 2012 at 4:02 PM, Glenn Maynard wrote: > On Sat, Sep 1, 2012 at 11:49 AM, David Bruant (mailto:bruan...@gmail.com)> wrote: > > A Sync API for workers is being implemented in Firefox [1]. > > I'd like to come back to the discussions mentionned

Re: Sync API for workers

On 09/01/2012 11:19 PM, Rick Waldron wrote: David, Thanks for preparing this summary—I just wanted to note that I still stand behind my original, reality based arguments. One comment inline.. On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote: Hi, A Sync API for workers is

Re: Sync API for workers

David, Thanks for preparing this summary—I just wanted to note that I still stand behind my original, reality based arguments. One comment inline.. On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote: > Hi, > > A Sync API for workers is being implemented in Firefox [

Re: Sync API for workers

On Sat, Sep 1, 2012 at 11:49 AM, David Bruant wrote: > A Sync API for workers is being implemented in Firefox [1]. > I'd like to come back to the discussions mentionned in comment 4 of the > bug. > > A summary of points I find important and my comments, questions and > co

Sync API for workers

Hi, A Sync API for workers is being implemented in Firefox [1]. I'd like to come back to the discussions mentionned in comment 4 of the bug. A summary of points I find important and my comments, questions and concerns # Discussion 1 ## Glenn Maynard [2] Use case exposed: Ability to cancel