Node is non-blocking and will always be. That's the core concept of node. However there are other use cases. I believe the original question was asking if there was a way to have a blocking system (which is simpler in many respects), but only diverge from node as much as required.
The one question I have with such a suggestion is how much code do you expect to share with the node ecosystem? Anything that does I/O or uses timers won't be portable across the systems. About all that can be shared is pure-js computation (like most of the code in node's path module). All that's required to achieve this level of compatibility is to use a es5 javascript engine. Yes blocking code is simpler, not just in terms of avoiding all the callbacks. Take back-pressure in streams, for example. In a blocking system, you're blocked till the kernel can consume the data. Instance bac-kpressure built-in without needing drain and resume. You system would be limited to doing one thing at a time, but often that's ok, especially for shell-script type use cases. Read up on binding to V8 (or spidermonkey or javascript-core) and start to make such a system. libuv won't be much good except for maybe cross-platform sync fs. The pure JS modules from node can be used mostly as-is. On Mon, Apr 2, 2012 at 8:16 AM, dhruvbird <dhruvb...@gmail.com> wrote: > I think that the sync API is useful (and I extensively used it) for > shell scripts mainly. > > Especially the following API *should* (in my opinion) have sync > alternatives (maybe a separate module so that there is NO confusion > what-so-ever). > > 1. Filesystem (already exists) > 2. SQL (sqlite/mysql/pg/etc...) - I don't think all have sync > alternatives > 3. http (basic implementation: https://github.com/dhruvbird/http-sync > ) > 4. Basically [3] speaks about blocking network calls > > IMHO, if you want to implement anything that isn't reactive to user > input (something like a batch process), then sync APIs are much > cleaner to work with. On the plus side, if you are invoking these API > many times (for example processing wikipedia pages for every day hit > counts), then the sync API would probably have a smaller constant > overhead per call. > > Regards, > -Dhruv. > > > On Apr 2, 5:27 am, Michael Nisi <michael.n...@gmail.com> wrote: > > I think the Sync alternative functions in core should go entirely. > > They clutter APIs (and mentalities). > > > > > > > > > > > > > > > > On Mon, Apr 2, 2012 at 10:53 AM, Oliver Leics <oliver.le...@gmail.com> > wrote: > > > Asynchronicity in Node can not be made optional as it is (by design) > > > the default. > > > > > On Mon, Apr 2, 2012 at 4:20 AM, Olivier Lalonde <olalo...@gmail.com> > wrote: > > >> 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. > > > > > Please, have a look at streamline.js > > >https://github.com/Sage/streamlinejs > > > > > It kind of reveres your proposed solution by giving every async > > > function the same callback that turns the async function into a sync > > > function (aka: you can write code that looks synchronous) > > > > > Short example: > > > > > var s = fs.stat(path, _) > > > console.log(s.size) > > > > > The underscore "_" is the callback you have to give to every async > > > function to turn it into a function that behaves like a synchronous > > > one. > > > > > I would really like to know if that might work for you. > > > > > -- > > > 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 nodejs@googlegroups.com > > > To unsubscribe from this group, send email to > > > nodejs+unsubscr...@googlegroups.com > > > For more options, visit this group at > > >http://groups.google.com/group/nodejs?hl=en?hl=en > > -- > 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 nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
