Re: What would _you_ like in a Lua CMS?

2009/9/28 David Given <dg@cowlark.com>

Petite Abeille wrote:
[...]

Hmmm... so... HTTP -> Apache -> (Fast?)GCI -> WSAPI -> stuff... what about HTTP -> stuff instead?

You mean, do an HTTP mini-server in the CMS app itself?

There are four major problems with this approach:

- doesn't play nicely with a third-party web server; you either end up having to run two outward-facing servers on a single box, or else have your main web server proxy to the CMS server, which is usually a pain;

- HTTP ain't as simple as at looks, particularly when dealing with stuff like multipart, transfer encoding, negotiating compression and so on; targeting something like WSAPI makes all these problems go away, as the main web server does it for you;

- having two HTTP servers means that you've double the chances of exposing a security flaw to the outside world; WSAPI nicely isolates you from the web server proper, making it very easy to run your client code at reduced privileges;

- _javascript_ security policies mean that it's a pain in the arse to split a complex site between two web servers; this means that it can become rather hard to, for example, server static content from lighttpd and dynamic content from your CMS server; life becomes much easier when you can serve everything from a single server.

I have actually in the past implemented a web app using my own mini HTTP server. This was before I knew about Lua, so I actually did it in LambdaMOO code. It *worked*, but if I'd known in advance what a pain it would be, I wouldn't have done it like that...

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "They laughed at Newton. They laughed at Einstein. Of course, they
│ also laughed at Bozo the Clown." --- Carl Sagan