From: Zoran V. <zv...@ar...> - 2005-10-17 08:14:58
|
Am 17.10.2005 um 03:54 schrieb Stephen Deasey: > Are you sure Ns_NormalizePath() is broken? I haven't examined it, but > it's worth pointing out that it's most important use is normalizing > the *URL path*, called early at the start of conn processing in > request.c. > > The comment for Ns_NormalizePath() says "Assumes an absolute path", > which seems reasonable when thinking about just URL paths. > > We need to figure out whether Ns_NormalizePath() really is broken and > fix it, or otherwise resolve the confusion. > > Also, will [file normalize $path] do the right thing to a URL when > used on Windows? The main point is: ns_normalizepath is used to normalize *what* paths? The filesystem paths or URL paths? If former, than it is broken since normalizing a/b should not yield /a/b. If latter, than it is merely a point of definition as in URL-space there is nothing like the "current directory" concept. The fact that ns_noramlizepath lived in tclfile.c leads me to conclude that it is ment to be used on filesystem paths. What you're saying is that it is primarily used to normalize URL paths. Well, we both may be right or wrong, but this is a very good example of a poorly defined API. Now, I would not like to leave "ns_normalizepath" as-is. It can very easily make people think it can be used for filesystem paths (which it can't). OTOH, replacing it with [file normalize] would hit anybody doing URL path operations (I did't think of that possibility, unfortunately). So what are our options? Add ns_normalizeurlpath and declare ns_normalizepath obsolete? Add -file | -url options to ns_normalizepath? Cheers Zoran |