Okay, the last little bit of follow up here ...

> For what it's worth, using an invisible table for Web page layout is 
> possible not a good example to use when defending hacks versus 
> "brilliant discovery", as some may see it as tending more towards the 
> former.   

It's kind of funny, but that's exactly why I used that
as an example. :) Anyone who worked with Web pages in
the mid-nineties will remember how the "invisible table hack"
(and that good ol' invisible spacer GIF trick -- those were
the days) turned a medium which had been designed for dry,
academic papers into a real publishing medium capable of
handling an infinite diversity of formatting options.

For the longest time, the invisible table "trick" was
your only option for creating moderately complex page
formatting -- until CSS finally came along to provide a
bit of relief. Although I do feel compelled also to point
out that despite the relentless pronouncements of CSS's
superiority and correctness from the Standards Community, and
the separation-of-content-and-presentation zealot-types, in
reality CSS's padding/width property interactions are just plain
broken, and you can't even do the simple vertical centering of
elements that was so easy and straightfoward in the table-based
layout "hack" that it's supposed to be saving us all from.

I'm not saying Standards are worthless, obviously, but a
religious belief in their all-encompassing authority can
seriously trip you up. I would much prefer a discussion on
the real-world technical merits, because I actually *use*
this stuff on a daily basis.

> former.  In any event, there is a broad range of things one can do to 
> achieve certain results.  Maybe the real issue is whether a given tool 
> offers sufficient means to achieve a goal, even if that means is not one 
> everyone finds to be the easiest or the most familiar.

This is actually a very good counter-argument. Parsing stuff
out of cgi.query_string is trivial, as noted in previously. Ruby
makes it way easy to customize and code around these limitations.

However, I would argue that if a change does not penalize
people familiar with the current implementation, and it makes
it easier for a significant slice of the population -- and
it does not contravene any Standards, what arguments are left
against implementing it?

> (On a side note, I never used the word "icky", nor referred to anyone as 
> a rube, a dolt, or as wet behind the ears. Those are your words, not 
> mine.  Sorry if I touched a raw nerve in my post.)

To be completely fair, the word actually used was "distasteful,"
which is a far more grown-up word than "icky," :-) Sorry if
I overreacted. It was just the unfortunate combination of
dismissive tone ("bad hack, "inexperienced") and apparent lack
of actual knowlege about the specific subject in that bit of
the post that got me a kind of testy. Again, serious apologies.

> Most importantly, this is not the place to have a discussion on the pros
> and cons of different techniques for Web site development.  Obviously
> there is disagreement on the appropriate use of certain options, but
> none of this means much to core Ruby development.

Well, my original post was to submit what I hoped might be
a helpful patch to cgi.rb, which is part of the Ruby core --
and is of course the default library for Web programming with
Ruby. Talking about a patch for the Web programming lib is
unfortunately almost guaranteed to involve *actual examples
of Web programming.* I realize it's not as sexy as stuff like
threading and race conditions, so I'm really trying to keep
it to a bare minimum.

> I would prefer that any code in a Ruby Web lib adhere to any applicable
> specs and RFCs; how people chose to exploit what falls out of this is
> their business.  There are any number of ways to pass application
> parameters in a URL (see del.icio.us, for example, or rails), and given
> how trivial it is to extract the data I am skeptical of claims they
> belong in the core library.

That's kind of the issue. There's nothing in RFC 2616 (HTTP/1.1)
even remotely specific enough about the actual form data and
query string data to know whether it's acceptable or not. And
the CGI spec of course specifies pulling the actual form
data out of stdin for POSTs, but is silent on the issue of
a query string in addition to the form data -- I'm guessing
this is because the data is manifestly sitting there after the
question mark on the requested file path, and it's up to the
program to decide how (or whether) to allow the programmer to
interact with that data.

There's nothing in there that forbids it, but of course the
idea is not specifically mentioned either. So it's obviously a
good bet not to make any changes to what seems to be a really
good implementation of the CGI spec -- especially when Ruby's
flexibilty provides easy ways to code around limitations like
that.

There's something about that that seems kind of Amish to me
(i.e., the people who don't use modern conveniences like
electricity and cars because they are not mentioned in the
Bible) -- but hey, it's called "cgi.rb," after all. I guess
that in itself is a good reason not to make it into anything
other than a solid example of old-school CGI.

Thanks everybody.


Matthew