Re: What would _you_ like in a Lua CMS?

[Petite Abeille <petite.abeille@...>]

On Sep 28, 2009, at 1:18 AM, David Given wrote:

> 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?

Yes, the application "speaks" HTTP natively.

> 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;

Always been under the impression that HTTP is meant to be proxy'ed.  
That apparently some common web servers make it difficult is, well,  
unfortunate... for those web servers that is :)


> - 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;

Ditto with proxies, you can leave each proxy to specialize in whatever  
it does well. Very similar to the basic concept of stdin/stdout in  
Unix. Not every tool needs to implement everything. Instead, one can  
pipeline processing from one to the other. The lingua franca being HTTP.

> - 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,

I always wonder why people want to be "isolated" from HTTP: what's the  
benefit of ignoring the most fundamental protocol a web application is  
supposed to deal with? A bit like wanting to access a relational  
database, but not wanting to bother with SQL.

> making it very easy to run your client code at reduced privileges;

One could argue the other way around:

"Complexity is insecurity"
http://www.daemonology.net/blog/2009-09-04-complexity-is-insecurity.html


> - 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.

One doesn't have to expose implementation/deployment details to the  
outside word. How one system is setup internally is one system private  
business.

> 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...

Fair enough :)

Cheers,

PA.