Alexander Gladysh wrote:
Wow, that thread become a huge one. :-)
Sorry for delayed replies.
I have been pondering on a proper niche for luafcgid. It doesn't make sense
to create YaWSAPI, so I think my focus will be on a 'lean & mean' setup for
web apps written in Lua. The intended audience would be large RESTful
transactional gateways and perhaps embedded systems (routers & whatnot).
I don't plan to add much more then header io, puts/gets/parse and the misc
housekeeping related stuff (flush/watchdog/exit).
I must be missing something here, but why do you need a separate
parser? What's wrong with gmatch or LPeg?
Is this because of string interning?
Nothing is wrong with custom Lua solutions. I encourage them and use
them myself. I have my own Lua x-www-form-urlencoded string parser,
along with a small bag'o'tricks that I require() in many web scripts. I
just wanted to include few basic "batteries" to help when writing quick
and dirty scripts or for those moving over from PHP. The built-in parser
is only intended for HTML spec form processing (like those posted from a
web browser). But it does make sample scripts beautifully simple to help
entice more victims into the Lua webapp world.
As for string interning, the parser is written for pure speed with a nod
toward safety (only valid hex % encodes, all others ignored - etc.).
Since it makes a local temp copy of the string, it isn't really any more
or less memory efficient then using a Lua parser.
On a side note and to throughly beat a dead horse; persistent states
mean that require() only hits the disk and compiler once for the
lifetime of the state, which amortizes any overhead of using multiple
Lua modules across thousands of requests (or more). And I use lots of
C/Lua modules personally. I mean LOTS. A couple dozen at times. Hence
the obsession with tightly managed persistent Lua states.
A remote telnet debugger
interface ala gdb might be nice, but that is currently on the
far-off-fairyland part of the schedule.
You mean remdebug-like functionality?
Yup, just without the dependencies. I was planning on simply doing a C
port of remdebug if possible. In pure C, without any external modules,
"simple" being a tremendous understatement of course. Hence the
far-off-fairyland scheduling.
In the meantime (which could be forever), I would highly recommend
people using remdebug with luafcgid.
_______________________________________________
Kepler-Project mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
