From: Thomas Hurst <tom.hurst@...>
Date: 2002-04-29T05:32:01+09:00
Subject: CGI API Rant

Is it just me, and do I just need to use it more to see how great it is,
or is cgi.rb's API a bit... uninspiring?

Looking at the page on Ruby CGI in Programming Ruby, it seems one of the
main parts of cgi.rb is to do with HTML generation; transforming strings
into HTML entities, building fragments and entire pages of HTML (to out
of date standards), etc.

I don't know about you, but I'd rather see things like that as part of
their own module.  The CGI module should be there to provide an
interface to HTTP; the form valiables, the cookies, the uploaded files,
details on the request, and powerful control over the response.

I fail to see how HTML generation makes a good mixin for cgi, when
sessions (something you're rather less likely to want to use outside
CGI) have to be set up externally.

I'm also rather concerned over sentences like:

"Returns a string containing the given headers (in the MOD_RUBY
environment, the resulting header is sent immediately instead)."

Isn't one of the points of having an API like cgi to make things like
this transparent?  I don't want to end up writing one version of my code
for CGI, one for mod_ruby, and another for FastCGI, just because the
interfaces (which are otherwise taking about the exact same thing) don't
match up.

What I might like a CGI API to look like (more to invoke
comment/discussion than anything else):

Seperate objects for the request and the response.  I may want to
parse a request but have utter control over the response.  I might not
care about the request and take the fact that my script is running as
reason enough to generate a response.  A smaller object can be wrapped
more easliy to cache a response, try out a new API, build in response
gzipping, etc, without also having to delegate all the form accesses and
everything else related to the request.

The request object should make it clearer where data comes from:

request.params.get
request.params.post

Rather than just:

request.params

Obviously, if the programmer doesn't care, he can just use params[], but
almost always I want to be able to specifically specify where I expect
data to come from.

The response object needs to be flexible.  One point for sending data
that is difficult to access from inside is not very nice
(cgi.out(header/cookie) { data }), and can be rather opaque.

How about something like:

response.buffer = true
response << '<h1>Title</h1>'
response.header('Key', 'Value')
response.cookie('Foo', bar)

h = HtmlGenerator.new('xhtml-1.1')
response.body = h.html { h.body { response.body } }
response.send

I don't know about you, but I feel more comfortable with an interface
like this, there the response can be built up piece by piece and the
exact behavior can be set up progressively.

Oh, a cross-platform, popular, stable, flexible and easy to use
embedding system like PHP would be nice too, since I get pretty
obsessive when my scripts take >0.1s to execute; interpreter startup and
CGI setup can take 150% of that.

Anyone fancy shifting me to a parallel Universe where mod_ruby is on 60%
of web servers? :)

-- 
Thomas 'Freaky' Hurst  -  freaky@aagh.net  -  http://www.aagh.net/
-
In an organization, each person rises to the level of his own
incompetency
		-- The Peter Principle