Re: Semicolon's for all
robm@ncsa.uiuc.edu (Rob McCool)
Message-id: <9401020104.AA10101@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Sat, 1 Jan 1994 19:04:44 -0600
In-Reply-To: Charles Henrich <henrich@crh.cl.msu.edu>
"Re: Semicolon's for all" (Dec 31, 5:15pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Charles Henrich <henrich@crh.cl.msu.edu>, rst@ai.mit.edu (Robert S. Thau)
Subject: Re: Semicolon's for all
Cc: www-talk@nxoc01.cern.ch
Content-Length: 5528
I feel sorry for Ari, wherever he is, getting back to all 3000 lines of this
argument.
/*
* Re: Semicolon's for all by Charles Henrich (henrich@crh.cl.msu.edu)
* written on Dec 31, 5:15pm.
*
* This whole argument is getting rather
* silly, Im amazed at the massive pushback at adding something that wont break
* anything, even when CGI is still in its infancy. What happens in a year
* when folks want to add something and CGI is well entrenched?
But it WILL break something! First of all, I don't see the benefits as being
compelling enough to merit the changing of the specification. The benefits
that I've seen brought up have been:
1. It does not require the server to grope through the filesystem with stat
calls.
2. It's cleaner and We Would Really Like It Better This Way.
#1 may be valid, but it has been shown that the groping can be reduced to
1-2 stats. #2 I consider an opinion judgement and not compelling enough to
merit a change to the spec.
Now, as far as breaking something, let's consider current implementations.
The CERN server has extra path information available to its htbin scripts.
NCSA httpd 1.0 as we're all painfully aware has extra path information
available. Both of these are transparent, i.e. they're both
/cgi-bin/script/arg1/arg2.
Let's say we decide to adopt the ; as the start of the extra path
information, and let's also say that the server, if it doesn't find a ; and
doesn't find a script at /cgi-bin/script/arg1/arg2, should perform the
backward compatible groping to find path information. Under this system,
someone using transparent path information which happened to have a ; in it
would have his/her script break.
Just like the problem of HTTP/0.9 documents just happening to start with the
string ``HTTP/1.0'', a seemingly trivial backward compatible change turns
out to not be so trivial. Are you starting to understand why we're so
``inflexible''?
So, it's all or nothing. We either change to mandating that path information
start with a ; or we don't. I have not seen a compelling reason why we
should throw the current scheme overboard and adopt the new one. Please,
provide one.
* This morning I absolutely needed the semicolon syntax to accomplish what I
* want in any clean manner.
Since I cannot seem to find any references, can you please explain in
graphic detail what exactly you are trying to do, why doing it under the
current setup is impossible or difficult, and why the semicolon syntax makes
it all better? Some concrete examples of why this addition to the
specification are necessary would help the argument greatly.
* It took exactly 2 additional lines of code to the
* server.
How much code needs to be added to any given server is completely irrelevant
to the decision of whether or not to change a protocol, unless the amount of
code to add is so large that it becomes prohibitive. It does break
something, it will cause confusion for a very LARGE base of script authors
(who now have to address their scripts in a new way), and I really don't see
just what will be gained by doing so except headaches for me answering tech
support questions!
* Im still amazed at the inflexibilty you folks are imposing on
* something so new, that hasnt even begun to be used in all possible
* situations it has been designed for.
Again, all of the arguments I've seen have been based on extremely
subjective terms like ``elegant'' and ``clean'' which I am still not
convinced I can agree with.
Perhaps it could be percieved that I am being inflexible to new ideas, but
consider my viewpoint. Changing the specification for what appears to be a
trivial reason, with a change which WILL BREAK existing scripts is something
I consider only for the most compelling of reasons. I have not been
convinced that your changes do anything except help John sleep at night and
make your AFS server run a little faster. I'm looking for practical
situations and examples as to why the current specification is not good
enough and we need to add things to it.
By the way, when new and compelling ideas are brought up, then CGI/1.1 will
be designed, specified, and implemented. As more and more situations are
dealt with by script authors, I'm sure that these ideas will occur to more
and more people. Please understand that changing the specification,
especially one which is NOT backward compatible, is not something I consider
lightly.
* Its okay, I dont mind adding 2 lines
* of code to every new release, its too bad that everyone who finds themselves
* in my position will also need to do so.
*/
Again, can you please tell us what your ``position'' is so that we can
understand why your arguments are compelling?
Anyway, in a later message, John Franks pointed out something interesting,
and I just went back and verified it. The current speicifcation says nothing
about how you're supposed to get the path information, it just says that the
information comes at the end of the path. Therefore, a server author like
John could conceivably decide to impose the restriction that path
information must start with a ; when accessing a script under GN and still
be fully compliant to CGI/1.0.
It would disappoint me to have GN act in a very different fashion than other
servers since the entire point of this exercise was to make a unified
gateway interface, however, as I've argued in the past, the URL after the
third slash is the server's business. Therefore, if he wants to do that, he
is within the specification to do so.
--Rob