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 workers, not only for efficience, but also for having only one programming model so you can easily interchange your code between workers and main thread and also maybe Node.js. 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... :-) --Mike P.S. Of course there's room for disagreement about whether synchronous APIs are even a good idea even for the Workers case - http://infrequently.org/2013/05/the-case-against-synchronous-worker-apis-2/ Good to know I'm not the only one... :-)
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 disagree because of lack of experience with asynchronous APIs, is mistaken. APIs must be designed around how programmer's minds actually work, not how you'd like them to work. I agree that APIs should have the least-surprise-factor, but are you sure that's the reason why we use to program in a synchronous, linear way? Because I've always though it was an heritage of the batch-processing machines of the '60s... I don't believe event-oriented programming fit bad with how humans thinks because the nature is event-oriented (if this then that), and I don't believe I'm an alien so that's the reason I think in a different way... but the required POSIX-like APIs would be better developed as external libraries on top of the asynchronous ones. You can't build synchronous APIs on top of asynchronous APIs without the mechanism this thread is specifically about. I've always been taught that you can implement one on top of the other... :-/ Obviously, asynchronous on top of synchronous is fairly easier thsn in the other way...
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 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 and easy as synchronous APIs, and that people only disagree because of lack of experience with asynchronous APIs, is mistaken. APIs must be designed around how programmer's minds actually work, not how you'd like them to work. I agree that APIs should have the least-surprise-factor, but are you sure that's the reason why we use to program in a synchronous, linear way? Because I've always though it was an heritage of the batch-processing machines of the '60s... I don't believe event-oriented programming fit bad with how humans thinks because the nature is event-oriented (if this then that), and I don't believe I'm an alien so that's the reason I think in a different way... but the required POSIX-like APIs would be better developed as external libraries on top of the asynchronous ones. You can't build synchronous APIs on top of asynchronous APIs without the mechanism this thread is specifically about. I've always been taught that you can implement one on top of the other... :-/ Obviously, asynchronous on top of synchronous is fairly easier thsn in the other way...
RE: [streams-api] Seeking status and plans
Date: Fri, 11 Oct 2013 08:47:23 -0400 From: art.bars...@nokia.com To: tyosh...@google.com; feras.mou...@hotmail.com CC: public-webapps@w3.org Subject: Re: [streams-api] Seeking status and plans On 10/11/13 8:05 AM, ext Takeshi Yoshino wrote: On Thu, Oct 10, 2013 at 11:34 PM, Feras Moussa feras.mou...@hotmail.com mailto:feras.mou...@hotmail.com wrote: Apologies for the delay, I had broken one of my mail rules and didn't see this initially. Asymeric is correct - there have been a few threads and revisions. A more up-to-date version is the one Asymeric linked - http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/streams.html The above version incorporates both promises and streams and is a more refined version of Streams. From other threads on Stream, it became apparent that there were a few pieces of the current Streams API ED that were designed around older paradigms and needed refining to be better aligned with current APIs. I think it does not make sense to have two different specs, and instead have a combined one that we move forward. I can work with Takeshi on getting his version incorporated into the Streams ED, which we can then move forward with. I'm happy to. OK, thanks Feras and Takeshi. Re PubStatus, I added Taekshi as an Editor and update the Plan to reflect the impending integration. I think it would be helpful if Feras' spec was updated as soon as possible to clearly state the intent to integrate Takeshi's spec. -Thanks, Art The spec has been updated with a note clarifying the state. I will work with Takeshi on getting the ED updated accordingly. Thanks, Feras
