Personally I like the node style APIs like event-emmiters, http, etc. and sugar like objects while using them heavily inside of my luvit modules.
I think 'luvit' should stay as it is in the manner of using it as replacement for node.js. вторник, 21 октября 2014 г., 22:30:54 UTC+3 пользователь Tim Caswell написал: > > Since working on luvit became my full-time job, I've been super busy > paying off technical debt and cleaning up the lower layers and now it's > time for the interesting high-level discussions. > > So first to recap the current status. I've finished rewriting my > libuv-lua bindings. The code can be found at https://github.com/luvit/luv. > This has much better test coverage than the previous version and more > closely follows libuv. Also it uses the new libuv 1.x APis and is > currently built against libuv 1.0.0-rc3. > > Next there is a small project known as "luvi > <https://github.com/luvit/luvi>". This builds a luajit binary with the > luv bindings baked in. Also it has a tiny bootstrapper that allows LÖVE > style packaging. Simple write your app as a folder of lua files with main > being at "main.lua". Then zip this folder and append it to the luvi binary > and you now have a self-contained binary for your app without ever needing > to build luajit or luv yourself. (I'll publish binaries for all popular > platforms. Windows version can currently be found on appveyor > <https://ci.appveyor.com/project/creationix/luvi/build/artifacts>. > > The next step is to decide how to integrate this new base into luvit > itself. I have a few questions for the community. > > 1. Are you set on the node.js clone APIs currently in luvit? > > 2. Which sugar APIs from luvit do you depend on? (event emitters, objects, > streams, net, etc) > > 3. Would you like freedom to try other async styles (coroutines, channels, > etc)? > > 4. How important is the ability to ship a single binary for your project? > > 5. Would you rather use luv as a module to vanilla lua or luajit (perhaps > through luarocks)? > > I'm not in love with many of the node.js APIs even though I was there when > they were originally designed back in 2009. In particular I think the > stream interface in node is pretty bad and complex. Luvit currently > doesn't take advantage of coroutines in lua which could dramatically > simplify async work. > > I propose we break out the node.js style API sugar into a standalone > library that could be imported to a project for folks who prefer this > style. This would leave room for other styles and expose the raw > underpinnings in luvi for people like me who like working closer to the > metal. > > I'm also considering a package management system for sharing and reusing > such modules. I want to make it trivial for a community to start growing > around this tiny core and see what's important to various people. > > I've talked some to the virgo agent <http://virgoagent.com/> team at > Rackspace (of which I'm a member). I'd love to hear from someone on the > Torch7 <http://torch.ch/> team and anyone else who uses or wants to use > luv or luvit. > > Let me know what you think. > > -Tim Caswell > @creationix > > -- You received this message because you are subscribed to the Google Groups "luvit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
