RE: Xavante / Cgilua interaction

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

> On Monday 01 August 2005 5:01 pm, William Trenker wrote:

> > Javier wrote:
> > Is there a formalized way to "communicate" between a custom Xavante
> > handler and customized Cgilua handlers so that any Xavante request or
> > response data can be made available to Cgilua scripts?
>
> we haven't 'formalized' any communication between handlers
> and CGILua scripts. since any client request is finally managed by only
one handler, any
> 'communication' is a kind of inter-request persistence.

Besides, it's important to notice that Xavante does not assume CGILua and
vice versa. In other words, we don't want to bind CGILua to Xavante in any
way, that's why SAPI is there for.

> > Another example of passing data from the customized side of Xavante to
> > Cgilua scripts is the match string determined by
> > xavante.httpd:parse_url().  I want one of my Cgilua scripts to
> > participate in decision making regarding the value of the match.
> > Since Xavante puts just about everything it determines as a value in
> > the req table, it would be very handy to get at it in
> Cgilua scripts.
> > But I want to take advantage of the security of the virtual
> > environment so I would like my custom Cgilua handler or open function
> > to limit what xavante-provided data is passed into the Cgilua scripts.
>
> this is interesting.  maybe we could add req/res to the SAPI
> record, but discourage its use to only when there's no other way to do it
> (like the match string).  of course it could be much cleaner to just
define a
> "XVTE_MATCH" servervariable.  any opinions on that?

I prefer the "XVTE_MATCH" servervariable approach, so SAPI would remain the
same.

> > In the spirit of attempting to use the design-intended user-defineable
> > pieces, I've tried accessing the cgilua API (eg:
> > cgilua.addopenfunction() ) from within a custom xavante handler, but I
> > get an error from require"cgilua" because the SAPI table hasn't been
> > defined yet. (Cgilua assumes it is being referenced by a module that
> > sets up SAPI.) So this is starting to go around in circles.
>
> this is part of what i didn't like about CGILua and moved me
> to write a new webserver: the WHOLE CGILua environment is rebuilt from
zero for each
> request.  even the cgilua.addopenfunction() calls to manage both scripts
and
> LuaPages are called each and every time.

Right, this is not the best solution, we agree. But the thing is that we are
still trying to figure out how to abstract the launching processes among the
different SAPI launchers. Most of them are persistant, but some are not. And
the persistant ones can be spread in more than one process, therefore
referencing different Lua states.

Of course a solution for one single launcher is simple, but things start to
get hairy when you try to include the others in the same solution. That's
why we started with a KDR (Knock Down Rebuild) approach for each CGILua
execution. This does not mean that we are not interested in offering a
persistence layer (and Stable is a first move).

Maybe SAPI could be extended to be seem as a true virtual launcher, offering
hooks for the whole process (init_sapi, init_response, handle_response,
close_response, close_sapi etc). Javier once talked about this and the
possibility of running Xavante over this improved SAPI. What would you think
of that?

André