>>> 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? Sorry, I was not clear enough. I wanted to say that wheel reinvention may create the feeling of a bloated and unfocused software. Also, if you do reuse existing modules, chances are that your users do already know them. This may help adoption. However, if all we're talking about is a HTML form parser, this is not a big issue. Perhaps I was too scared by its generic name "parser". :-) > Are you saying that it should be included instead? Well, you've said that you position luafcgid as a batteries-included software. This probably makes sense, so, yes, take one of the suitable modules and bundle it. I'm not sure if I myself like the idea of batteries-included anything (unless it is on Windows). >>> 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. Well, yes. > Let us just say I had a bad experience with that once. Then, perhaps, teach your PHP-adopters to use luarocks? > I also personally prefer self-contained software (as much as possible), > especially > for serious server use. Me too, but I feel that the public software has its own rules. Perhaps I'm wrong. I've got a feeling that you're trying (perhaps not conciously) to create your own ecosystem. Providing your own alternative implementations to existing modules sure does that. As the number of users (and, especially, the contributors) is limited, I feel that the software would have better chances to gain followers if it does not stray away from the mainstream too much. Maybe I'm overreacting. :-) >>> 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. I see. Like I said, I was scared by the generic name. >>> 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. Not sure if you would solve anything by dropping your replacement code instead. After all, if you would introduce enough replacements, you will be forced to invent your own module system to manage them. :-) > [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... Makes sense. I feel that I've overreacted. Sorry. But I was under impression that you want to rewrite everything your way. :-) > [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] I see. :-) > 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?" Yes, those are valid reasons. But still, how do you plan to get rid of all those dependencies *user's* code has now? To write code effeciently, client of such hosting would need a lot of third-party modules. :-) I may imagine some minimal built-in support library, all right. But you wouldn't cover everything... Alexander. _______________________________________________ Kepler-Project mailing list Kepler-Project@lists.luaforge.net http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project http://www.keplerproject.org/
