Re: Param Naming and Abbreviations

[Chris Hostetter <ho...@fucit.org>]

: OK, sounds reasonable, although I suspect your frequency based convention is
: going to be in the eye of the beholder.

absolutely ... but even if we all drank the same koolaid and agreed 
perfectly about how short something hsould be based on it's frequency of 
use, frequency of use changes.  "qt" is a nice short param that is 
boardering on deprecation, yet at the time it was introduced it was 
explicitly used in almost every request.

hindsight is 20/20.

another problem to keep in mind is local params: even if a param will be 
used extremely infrequently, it might be worthwhile to keep it relaly 
short if it's *allways* going to be used as a local param inside of the 
QParser syntax -- because the qparser will help document the purpose/scope 
of hte param.  people ocnvinced me that the facet.date.* params were too 
short when i first wrote them because date faceting was kind of a niche 
thing, and the params needed ot be better self documenting, but now that 
we have local params it seems silly to specify them as top level params, 
but in local params they see obscenly verbose.

: Has anyone actually documented/tested the "cost" of a URL of 100 chars versus
: one of 200 chars?  I don't know much how NIC's work, but I have a hard time
: believing that makes much difference when it comes to packets, buffers, etc.
: especially in comparison to optimizing the response side of things.

i don't have any hard numbers, but i've known people who looked into and 
concluded that having shorter URLs does help, but that it wasn't a big 
enough deal to go overboard at the expense of readability.  common 
sense says that all other things being equal you might as well pick a 
short one.

As i recall the biggest advantages were:
 - smaller keys in HTTP caches improved cache lookup speed.
 - reduction in size of request logs
 - easier to read various logs when troubleshooting (less linewrap to 
confuse people)

: time), I find it curious that so much is put into shortening params in a 200
: char URL (if that) to the point of near unreadability, in some cases, and yet

po-TAY-toe po-TAH-toe ... one url with short param names that you aren't 
familiar with may seem unreadable, but when you're skimming thousands of 
URLs where the param keys are all the same and what you really care about 
are the different *values* it's easier to find the anomolies when the key 
names are short.

: the responses (up until the binary response format was added) are so verbose,
: especially for XML (but even JSON isn't all that succinct) and especially when

hey man, why do you think the sml format uses <str> instead of <string> ?

(At one point i remember an argument for only single letter xml node 
names, and replacing 'name="..."' with 'n="..."' -- this was back in 
the really early days when i wasn't happy that Solar was going to be a 
webserver at all and just wanted an in memory service; but both that and 
a pure binary response format had already been vetoed by Yonik's boss)


-Hoss