[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: RES: CGILua future
- From: "Andre Carregal" <carregal@...>
- Date: Thu, 25 Nov 2004 13:22:47 -0300
While I have to agree with your arguments, may I suggest a different
Kepler separates the problem in three levels:
- A launcher is the lowest level communication layer, it just talks with the
- CGILua is a template processor (in fact the templates are called Lua
Pages) library that does not know about the web server and how the request
has been launched.
- A Kepler application is a series of Lua Pages and/or Lua scripts that make
something using HTTP, CGILua and other libraries.
>From what has been said about FastCGI and Session Affinity (SA), I think you
could benefit from CGILua and Lua Page functionality simply implementing a
session server (like the one on http://www.tfarmbruster.com/document.htm)
that presents itself as a CGILua launcher.
As long as you are able to maintain SA using this session server, the use of
VEnv would stop being a hindrance and offer you some scope containment
benefits. Or if you'd prefer, simply remove VEnv from the equation and you
can have Lua Pages using SA on a surely very fast setup.
My insistence on the use of CGILua is simply a matter of template
compatibility, so your solution would add another launching/developing
option to Kepler, instead of becoming another template processing option.
I know that I am obviously biased on my proposal, but I sincerely believe
that Lua Pages are a nice solution to template processing, and that the
faster they are handled the happier their users will be. :o)
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com]On Behalf Of Javier Guerra
> Sent: Thursday, November 25, 2004 10:02 AM
> To: Luiz Henrique de Figueiredo; Lua list
> Subject: Re: RES: CGILua future
> what i'm thinking now is to simplify things radically: i'll
> take just the
> fastcgi launcher of CGILua, and replace the lua-side with a
> minimal loop. to
> keep different applications separate, i'll run a different
> launcher process
> instance for each application (i think the apache .conf lets
> me do it easily)
> that means that each web app will have it's own lua state;
> one that doesn't go
> away after each request.
> on this environment, a small API would let the app register
> scripts referenced
> by the URL, and state objects referenced by a session cookie. no
> (de)serializing needed unless the app wants to make
> 'permanent' records (to a
> SQL db, usually)
> does this sound more Lua-like?