- From: Michael[tm] Smith <mike@w3.org>
- Date: Sat, 12 Oct 2013 11:43:26 +0900
- To: "piranna@gmail.com" <piranna@gmail.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, David Bruant <bruant.d@gmail.com>, Glenn Maynard <glenn@zewt.org>, "public-webapps@w3.org" <public-webapps@w3.org>, Andrea Marchesini <amarchesini@mozilla.com>
"piranna@gmail.com" <piranna@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 platform. The most obvious example here is synchronous > > filesystem access which is very commonly used in other platforms like > > posix and windows. > > > Synchronous APIs are easier to use since it's how things have been done > since decades ago, but I don't think they fit in a event-oriented > environment like Javascript, and more specially to some so time consuming > like filesystem and IO. I find it better to only develop asynchronous APIs > for this use cases. It would make sense to use synchronous APIs to help > porting current code for example from C/C++ to Javascript, but the required > POSIX-like APIs would be better developed as external libraries on top of > the asynchronous ones. 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. --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/ -- Michael[tm] Smith http://people.w3.org/mike
Received on Saturday, 12 October 2013 02:43:39 UTC