+1
Roughly, it would be ideal if there were *no* penalty; however, if
it's necessary for there to be some penalty, it shouldn't be
disproportionate.
Or, "non-GET SHOULD NOT be penalised more than GET, but if it is it
MUST NOT be unduly penalised."
Your final formulation is fine as well. Of course, "unduly" is a
judgement call that needs to be balanced with the other requirements.
Cheers,
On 06/02/2008, at 3:01 AM, Jonas Sicking wrote:
Ian Hickson wrote:
* "It should be possible to issue methods other than GET to the
server,
such as POST and DELETE." Add to this: "The solution must not unduly
penalise use of methods other than GET, e.g., with performance
degradation. Likewise, it must not penalise use of a particular
style of
URI, or the use of a large number of URIs."
I don't particularly agree. If we can optimise GET even more than the
others, then good, but we shouldn't cripple our design for GET just
because we can't get the other methods to be as efficient.
In conclusion, I am strongly opposed to removing the first
requirement
above, and strongly against changing the second requirement above.
I think we're reading different things into this, not sure which one
Mark meant. If it is meant as
"non-GET should not be penalized more than GET"
Then I disagree with having that as requirement. If it was meant as
"don't unduly penalize non-GET requests"
Then I agree with that but would add that we also shouldn't unduly
penalize GET requests, thus simplifying it to
"don't unduly penalize requests"
/ Jonas
--
Mark Nottingham [EMAIL PROTECTED]
