[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: CGILua future
- From: Javier Guerra <javier@...>
- Date: Tue, 23 Nov 2004 20:58:06 -0500
On Tuesday 23 November 2004 12:51 pm, Tomas wrote:
> > totally recreating the statelessness of PHP and old-style CGI!
>
> The environment is not totally recreated. VEnv inherits all
> globals from the original environment. Also, libraries loaded with
> require are "cached" avoiding reloading code from the file.
right, the startup time is far lower than old CGI, the only overhead seems to
be the creation of the new environment (and maybe garbage-collecting the old
ones). but the main advantage of Java that i'd love to see is the
persistence of in-RAM objects. J2EE has a lot of complex mechanisms to
reduce serialization and deserializations, those are possible just because
the object containers persist from one HTTP request to other.
a simple sessions library, like that of PHP, can make it easier to retrieve
objects from storage; but maybe the most Lua-like solution would be just a
global table where i could put any object (or tree of objects) that i want to
persist for another request. then, i just need a cookie to store the key.
maybe some extra features like setting a timeout to purge the object (to have
expiring sessions)
> The main reason is to protect one script from another.
that's what i guessed, but thought maybe there was another reason.
> > Also, i'm afraid that some queries can take a few seconds to be
> > processed, and the single event loop would make every query to wait
> > single-threadedly on a queue.
>
> Maybe I've missed the point but currently CGILua does not share
> Lua States over threads.
what i mean is, given the simple event loop, can i do overlapping requests?
it's important because some queries can take a few seconds to be processed.
short enough for a single user; but if another user can't get his requests
served meanwhile, we're in trouble.
> We'll release the next version (alpha 4) until the end of
> november. We included a sessions library which still needs thorough tests
> and some improvements but is working. The documentation also lacks some
> examples (but this is just another alpha :-) etc. Well, give it a try and
> tell us what you think!
i'd like to see it! at least see where the project is headed... my
requirements aren't too complex, so if your priorities are too different, i'd
have to roll my own.
is the alpha 4 code available anywhere?
--
Javier
Attachment:
pgp4QY5oU0Tek.pgp
Description: PGP signature