Oleg Podsechin

"I've been thinking about re-implementing this DHT implementation I wrote in Java 10 years ago in Node: https://github.com/olegp... Is this something others would find useful?" - Oleg Podsechin

"https://github.com/olegp/mcms" - Oleg Podsechin

"submitted by reddit to blog." - Oleg Podsechin

"Looks nice, but you should consider using the CommonJS specs so as to make it possible to run on existing platforms like RingoJS and Node." - Oleg Podsechin

"I've written something similar called MCMS: https://github.com/olegp/mcms" - Oleg Podsechin

"I read that part, what I'm saying is I'm targeting a different community which has little overlap with the front-end developer turned distributed systems engineer crowd." - Oleg Podsechin

"The project is called common-node, because it's a CommonJS compatibility layer for Node.js, i.e. it depends on it. I'm not very good at coming up with original names and that seemed to be self descriptive enough, so that's what I went with. I'm pushing for more of a Narwhal like approach, where the underlying platform & engine are irrelevant and one can have the same server side JavaScript code running everywhere. All higher level packages built on top of these CommonJS modules are completely independent of Node and hence won't use the word "node" anywhere in their names: https://github.com/olegp/commo..." - Oleg Podsechin

"I think the async vs. sync debate in the Node community stems from the fact that people see the two approaches as being polar opposites of each other. The truth of the matter is that an async approach is nothing new and lower level processes (interrupts etc.) have been async all along, Node has just exposed this asynchronicity to the user space in an accessible manner. Sync is an abstraction on top of async and as such has a number of pros, but also cons, compared to the lower level of abstraction that it relies on. Looking at any of my common-node examples (http://olegp.github.com/common... should make it clear what those are. So, you should view us "node-fibers guys" as your users (see interview with Linus: http://h30565.www3.hp.com/t5/F... rather than detractors & hopefully we will all be able to get along." - Oleg Podsechin

"I'd argue that Node is mature enough to use for any project. It's perfectly usable and simple enough for small CRUD websites & awesome for command line tools. Since you're coming from a synchronous environment, it may be easier to program in a synchronous manner, so do check out my common-node project: http://olegp.github.com/common-..." - Oleg Podsechin

"It would be fun to try and rewrite nodepad using common-node (https://github.com/olegp/commo... and a sync style of programming. I might give that a shot and maybe we could even start a regular series on that?" - Oleg Podsechin

"I think Node has now reached a stage where it's feasible to write general purpose apps on it, including CRUD webapps & command line tools and we're likely to see more of them appearing in the near future. I'm hoping that my Common Node project (https://github.com/olegp... be part of what brings about that shift." - Oleg Podsechin

"It's fascinating that people are going to this much trouble to be able to write server side JavaScript using Node. For most real world web applications, your app will be spending a tiny fraction of the total request/response cycle in the web tier, so why bother optimizing it in the first instance? Why not go with a synchronous, blocking platform like RingoJS (http://ringojs.org) or Akshell (http://www.akshell.com) instead and save yourself all the trouble?" - Oleg Podsechin

"http://www.akshell.com is trying to address some of these problems. - Akshell already provides a browser based IDE and hosting environment that allows you to write and deploy code very rapidly from any device & without the need to install and start a desktop development environment - It will be possible to fork+clone, commit and send pull requests via a GUI and without knowing Git - Profile pages for CommonJS packages and developers will make the experience more social and make it clear what the connections are between the various packages" - Oleg Podsechin

"I don't see why one should try to reproduce the event driven style of browser based development on the server. Instead, it's far more practical to build apps in an "API at the core" fashion, that is by first designing a RESTful API (perhaps with streaming support) that implements the business logic. This could then be accessed by any API client, be it a server side component for turning the one or more API responses into static HTML, a client based solution that generates the HTML within the browser or a native mobile app. As a result, your business logic would be written in a sync manner, and be easy to maintain, while making it easy to offer new functionality in some clients, without breaking others. This is our preferred approach at http://www.akshell.com - which is a server side JavaScript platform running V8 with synchronous I/O." - Oleg Podsechin

"We have written our own synchronous server in C++, which is modeled after Apache MPM and uses V8 as the JavaScript engine. We will be open sourcing it soon and providing distro specific binary packages, so watch this space and follow us on Twitter at http://twitter.com/akshell_com" - Oleg Podsechin