: 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
