Async is a lower level of abstraction than sync, so having sync versions of existing calls wouldn't be as useful as it may first seem.
For example, to make an HTTP request and read data from it, you would still need to make multiple calls: first to make the request, then upon receiving the socket event and after that for every data event. In fact, you wouldn't even be able to handle errors in a completely synchronous manner, since the error event could be fired instead of the socket event and you would have no (easy) way to wait for both in synchronous code. Now, if you still want to achieve what you're asking for, there's the node-sync library (https://github.com/0ctave/node-sync) which modifies the Function prototype. If however you want to work at a higher level of abstraction with an API designed to be synchronous from the start, you should check out my Common Node project (https://github.com/olegp/common-node). The library also addresses the issue of fragmentation that you mention by making it possible to run the same code on RingoJS and other CommonJS compatible platforms. Oleg On Monday, April 2, 2012 5:20:01 AM UTC+3, Olivier Lalonde wrote: > > I'm sorry if this has been discussed before, but I couldn't find anything. > This a modest proposal to introduce sync APIs in Node.js > > A lot of people would like to use Javascript for their web backend, but > don't want to program in an async style (I believe those reasons have > already been discussed at length). > > As it stands right now, it is practically impossible to program in Node.js > in a sync style, since most core modules and native extensions only provide > an async interface. > > I believe there would be an easy way to change the status quo without > impacting developers who chose to adhere to a strict async style. The > solution I propose is simply a pattern for writing I/O APIs: every I/O call > should be async *unless* no call back is supplied, in which case the I/O > call should be sync and use return / throw statements instead of calling a > callback. > > There is probably a flaw in my reasoning since I'm probably not the first > one to come up with this pattern. That being said, I think it would be an > elegant way to make both async/sync fans happy while keeping all the > backend JS community focused on one project rather than fragmenting the > community in multiple CommonJS server implementations. > > Thoughts? > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
