Re: Reasons for a Web Developer to use Lua?

[Justin Cormack <justin@...>]

Also I have started looking at the nginx Lua bindings, which are really
nice https://github.com/chaoslawful/lua-nginx-module

These give you an async framework, but much more usable than say node.js
because it uses coroutines. Nginx has modules for a whole bunch of
databases, memcache etc that hook right in.

The next release of Apache will have Lua built in with hooks into the
engine, which might encourage more people to use it in web type
applications.

Justin

On Wed, 2011-03-16 at 17:13 +0800, Tang Daogang wrote:
> Zed's Tir web frameworks is based on Lua.  
> http://tir.mongrel2.org/home
> 
> And its' derivative Bamboo is too. 
> https://github.com/daogangtang/bamboo
> 
> On Wed, Mar 16, 2011 at 5:09 PM, Marc Balmer <marc@msys.ch> wrote:
>         Am 16.03.11 08:21, schrieb steve donovan:
>         
>         > On Tue, Mar 15, 2011 at 11:10 PM, Chris Babcock
>         <cbabcock@asciiking.com> wrote:
>         >> Lua may not have the obvious library support that Python
>         does, but the
>         >> basics are there and the APIs tend to be pretty stable.
>         >
>         > Sputnik really is so much more than a Wiki, although it
>         takes a little
>         > effort to get used to [1]
>         >
>         > The idea of versioned data as Lua tables is very powerful.
>         >
>         > The big Lua web effort has always been Kepler, which is
>         responsible
>         > for many of the library goodies for Lua (many of the
>         'canonical'
>         > libraries come from this project).
>         >
>         > My favourite from the Kepler stable is Orbit [2], although
>         Chris might
>         > not like its default ORM (but this is not compulsory; the
>         Sputnik
>         > versioned storage can be used as standalone libraries)
>         >
>         > There is a chicken-and-egg problem: wider use of Lua in the
>         web space
>         > requires more libraries, and these get written when there is
>         a need
>         > which is larger than an individual developer's itch, i.e.
>         when there
>         > is wider use of Lua.  In terms of flexibility and
>         performance, it's a
>         > natural fit otherwise.
>         
>         
>         FWIW, here is how we use Lua for Web-based applications
>         (actually the
>         backoffice for the arcapos POS solutions, www.arcapos.com, is
>         realized
>         this way):
>         
>         We have a small core in C, a Unix daemon process, that runs in
>         the
>         background and communications with a webserver (lightttpd,
>         apache) over
>         FastCGI.  The C core handles authentication and
>         authorization.  It uses
>         Neotonic ClearSilver as a template engine.  ClearSilver
>         functions are
>         exposed to Lua.
>         
>         For every user that logs in, a Lua state is created, a cookie
>         ties a
>         session to a Lua state.  In the GET or POST request we have
>         one field,
>         'op', which is the discriminator to decide what operation is
>         requested.
>          The operations are implemented in Lua.  Upon startup, Lua
>         code can
>         register functions for certain ops, and the function will then
>         be called
>         by the C core:
>         
>         http://whatever/app/index.html?op=some_action
>         
>         The Lua code would then register a function to be called for
>         some_action:
>         
>         register('some_action', function ()
>           -- do work
>         end)
>         
>         We are quite happy with this, it is reasonably fast and quite
>         secure (of
>         course I omitted many details here ;)
>         
> 
> 
> 
> -- 
> Nothing is impossible.
>