Alexander Gladysh wrote:
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.
Well, that is your decision, of course, but, if I were you, unless I'd
have a good performance reasons, I'd avoid reinventing the wheel here.
It may harm Lua users adoption.
How does using a custom parser in-house to provide advanced HTML form
functionality harm user's adoption? Are you saying that it should be
included instead?
I just wanted to include few basic "batteries" to help when writing quick and
dirty scripts
or for those moving over from PHP.
Why not include them right into your distribution then? Like Lua for
Windows does?
Can't the same be done with, say LPeg, and pre-packaged with your
scripts? You may even do require() for the user by default.
Packaging other people's projects into your own is a sure road to
madness my friend. Let us just say I had a bad experience with that
once. I also personally prefer self-contained software (as much as
possible), especially for serious server use.
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.
If the parser has the same cost as Lua, then why is it here?
No, it has the same memory cost. But it is much faster for larger posts.
I could have written/borrowed one in Lua and bin2c it and prepended it
to to each script loaded (hoping not to clash with any user
namespaces)... but then the C parser would already be written by then.
It is only 120 lines of C code after all. Barely a peep in that
language. There is no real cost to include it. Since I expose the data
sources directly (env.QUERY_STRING and req:gets) users are free to
ignore req:parse().
It also complies with HTML spec & RFC prescribed behavior, so there
shouldn't be any user confusion about the behavior of it versus using a
different 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.
Not sure I quite follow you here, sorry. You say that you do not
afraid the cost of modules, but instead of using existing modules, you
prefer to write your own. Right?
I am trying to make a web environment suitable for heavy production use
that allows (and encourages) using modules. But I have no wish to
clutter sysadmin's lives and servers with third party modules they may
not wish to have dropped onto their machines.
[WARNING, opinionated rant below]
This is about choice. I like having a choice which abstraction to use.
Any basic web framework that summarily includes LuaSQL (for example) is
not welcome on my servers. Don't get me wrong, LuaSQL is great and I use
it all the time. I even have it installed on many of my machines
anyways. But what about those installations that do not warrant it?
Should I be forced to install it simply because I want to serve dynamic
content?
The whole "let's bundle everything together that might remotely be
related & usefull" trend gives my gas.
So I include a basic parser because it is needed for the majority of
interactive webapps. But I will not infringe upon my potential user's
choice (wherever possible) about what gets installed on their machines.
It is a principle that I wish more developers followed...
[rant done]
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.
Why?
Too many dependencies for my personal comfort. See above rant for more
details. I will be using this project (in part) to pay my rent. Call me
overly picky if you want.
> I myself have a bad case of "not invented here" syndrome. But when one
writes a public project, especially one that is undermanned, it is
important to be focused on the main goal. You just can't rewrite
everything out there.
* * *
I like to think of it as 'custom engineered' syndrome. I only write my
own stuff when it is 1) easy and efficient to and 2) reduces
dependencies. I'm not writing my own webserver after all :P
[no offense to Raphaël Szwarc, that is one neat'o square peg you have]
Also, one benefit is that being this picky about unnecessary
dependencies can be one of the best ways to get something accepted by
large hosting companies (wink, wink).
I have known a number of small to large hosting company sysadmins over
the years, and just about the first question they ask about new tech is:
"That sounds like a great product to offer our customers, but what are
the install dependencies?"
I'm sorry for the rant above. Again, this is your project and your way
to do things. I hope I did not hurt your feelings or your motivation.
Alexander.
I always love a good banter. It helps focus and sharpen my own ideas and
thoughts.
_______________________________________________
Kepler-Project mailing list
Kepler-Project@lists.luaforge.net
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
