[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: What would _you_ like in a Lua CMS?
- From: Cosmin Apreutesei <cosmin.apreutesei@...>
- Date: Tue, 29 Sep 2009 13:40:15 +0300
>> 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?
>
> Do you write your programs directly invoking POSIX system calls and
> using primitive types? No, because while this may be the more "pure"
> method, it is more complicated and puts more work on you, the
> programmer. That's why Lua has the 'os' and 'io' tables instead of a
> 'syscalls' table - or tables at all. The reason WSAPI, WSGI,
> [Fast]CGI, etc. all exist is so that people don't have to try getting
> everything about HTTP right themselves. They have a layer that does it
> for them, and a layer that is guaranteed to do it well, so they can
> focus on the *application*, rather than the infrastructure.
It's incredible how we can fool ourselves that these so-called
abstraction layers are made to provide simpler/easier APIs to their
users. Lua's os and io libraries aren't made so that people don't have
to get _files_ right themselves :) Same with WSAPI, LuaSQL, etc. The
only reason to have those layers is so you can interchange the
backends. In exchange of that you get a library of limited
functionality, that sooner or later you'll have to bypass with
ridiculous hacks to access the functionality they abstract away.
Examples:
- lua io: hack it to get OS error codes
- WSAPI: send pseudo-http headers that only apache understands to
control compression.
WSAPI cannot put one bit of functionality in its API that isn't
supported (or can't be easily emulated) by all of it's supported
backends. This is the main force that drives the design of those APIs.
>From the user pov, these are totally arbitrary choices, not deliberate
exercises in elegance and simplicity.
If the primary reason to abstract http away would be simplification,
you'd have this put on a library instead. A library you can use if you
like when you like, and you can also _not_ use when you need not to
(you could even use two libraries on the same http stream). You'd have
both abstraction and control at the same time.
That being said, I acknowledge the bad feeling of isolation from http
that you get with these layers, both practically and theoretically.
> A bit like wanting to access a relational database, but not wanting to bother with SQL.
I think this analogy is accurate if you think about what O/R mappers
have done to poor people around the world :) At the same time, only
someone who has _implemented_ an O/R mapper can tell you how
delusional is the SQL-as-abstraction-layer view of SQL :) In all
RDBMSs that I've worked with, almost everything that's available in
the procedural API is also available in SQL form. Let's not confuse
abstracting functionality with merely abstracting the access method.
Ironically, dumbing down your use of SQL to the common set of
functionality available on all compliant servers goes against many
criteria for choosing a server in the first place :) but I diverge.
The unix way (chaining pipes) approach is as valid a model for http as
for any other protocol. IMHO the problem is merely cultural - very few
people code this way nowadays. Although complex programs, like postfix
for instance, work amazingly well using this awkward model (I admit it
though I hate postfix).