RE: HTTP Methods. Not just MGET.

> Incidentally, Roy states "doubling method space is evil", and shows a
> similar sentiment about halving method space, as HTML forms tends towards.
> Is this because it has been determined (through formal reasoning?) we have
> *exactly* the methods we'll ever need, or merely that only minor,
> incremental additions/reductions should be considered?

(Good, we're discussing the meta-issue here, that's more TAG-ish than the
specificis of MGET, I feel a bit guilty about introducing that fork).

I'd say that changing a known vocabuary/namespace is often evil, and something
to be done with caution. But there are a few things that affect just how much
caution we will need.

Changing a namespace in a way that doesn't allow for anyone to easily change it
is considerably more dangerous than a namespace that is designed to prevent
clashes. Creating a new XML element or attribute (which adds to the 'namespace'
of XML in general, not as that term is used specifically within XML) isn't at
all evil, because the XML Namespace mechanism makes that safe. C++'s namespace
mechanism makes new classes safe, but not entirely safe (because the namespaces
names themselves may clash) adding something to HTML was evil (and we all
suffered the fallout in the days of the browser wars). Did someone say there
was another MGET used elsewhere?

Changing a namespace in a way that doesn't allow for fallback is evil; new HTTP
headers and well thought-out additions to HTML aren't too bad, HTML
(pre-XHTML)additions that produce weirdness on other browsers was.

Halving the namespace as used by a particular use of a technology is safe,
inevitable, and often good. Halving the namespace supported altogether is evil
since it breaks expectations (servers should understand PUT, but don't have to
actually PUT anything).
Doubling will generally allow for backwards-compatibility in at least one
direction (in the specific case of MGET, clients that don't MGET aren't
affected).

The stronger the semantics of the terms in the namespace the likely a change is
to be evil (GET is stronger than If-Modified-Since, MGET is stronger than
x-WhateverJonThinksUpWhenBored).

Of course sometimes you have to choose between the lesser of two evils. In
fairness to Patrick I don't think he underestimates this in the slightest, and
I thank him for his patience in politely defending MGET against the repeated
criticism, partcularly from those of us who just have an istinctual response to
disapprove of additions to that particular namespace (and who are
"unconvinced").

I'm reminded of the story of someone suggesting at a C++ conference that people
should all be allowed to introduce new features, but they should have to donate
a kidney with each one - so they'd think very hard before suggesting one, and
would be physically incapable of suggesting more than two (the next speaker was
Strousup introducing exceptions and templates...).

-- 
Jon Hanna
<http://www.hackcraft.net/>
"…it has been truly said that hackers have even more words for
equipment failures than Yiddish has for obnoxious people." - jargon.txt

Received on Saturday, 28 February 2004 09:04:25 UTC