lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

And I think Sputnik is too complex and not clear on MVC rank separation to ordinary developers comparing to Django and TurboGears. That means Sputnik is not easy to use, but Tir and Bamboo is easy to use. You can try them.

On Wed, Mar 16, 2011 at 5:13 PM, Tang Daogang <> wrote:
Zed's Tir web frameworks is based on Lua.

And its' derivative Bamboo is too.

On Wed, Mar 16, 2011 at 5:09 PM, Marc Balmer <> wrote:
Am 16.03.11 08:21, schrieb steve donovan:
> On Tue, Mar 15, 2011 at 11:10 PM, Chris Babcock <> 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,, 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:


The Lua code would then register a function to be called for some_action:

register('some_action', function ()
  -- do work

We are quite happy with this, it is reasonably fast and quite secure (of
course I omitted many details here ;)

Nothing is impossible.

Nothing is impossible.