RE: RES: CGILua future

["Andre Carregal" <carregal@...>]

While I have to agree with your arguments, may I suggest a different
approach?

Kepler separates the problem in three levels:

- A launcher is the lowest level communication layer, it just talks with the
web server.

- 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)

Andre



> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br
> [mailto:lua-bounces@bazar2.conectiva.com.br]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?
>
> --
> Javier
>