Quoting [Thilo Kielmann] (Dec 13 2007):
On Wed, Dec 12, 2007 at 09:23:41PM +0100, Andre Merzky wrote:
Options:
(B) Add versions of the methods copy, link, move, and remove from ns_directory that accept a string parameter describing a pathname, relative to the CWD, (possibly) containing POSIX-style shell wildcards
Correction 1: also for permission_allow/permission_deny Correction 2: remove the limitation to relative paths
(C) Allow '*' as wildcard in URLs (in the path element part). Add an expand method for more elaborate wildcard expansion, which accepts a string and returns a list of URLs. Looping is in user space.
I am not sure if we came to a closure on 'Correction 2', but I think that Ceriels answer ("if you need abs paths, then do a 'cd()' to somewhere where you can use rel paths") is a rather inelegant workaround for a limitation which is not too well motivated, IMHO.
The motivation for relative paths is: an absoute path immediately becomes a URL, (well, a URL-shaped string)
Why is that? tmp/data.bin <-- relative /tmp/data.bin <-- absolute http://localhost/tmp/data.bin <-- relative http://localhost//tmp/data.bin <-- absolute There is no real difference here in appearance, apart from the slash leading the path element of the URL. I say its confusing to allow one form but not the other.
where we cannot have wildcards. This would LOOK LIKE allowing both strings and URLs for abolute paths, utmost confusing to the user (because of the subtle differences in acceptable syntax although both LOOK pretty much identical). It also feels like feature bloat.
I still consider 'C' a bloody hack because even the '*' violates URL syntax according to the RFC.
No, it does not. '*' is explicitely a valid character which can be used w/o encoding in the path element of any URL (in fact in any other element, too). See second to last paragraph in 2.2 on http://www.ietf.org/rfc/rfc1738.txt: Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL. Sorry Thilo, but I think thats pretty clear. The RFC does not prescribe the interpretation of '*' as wildcard, thats true. In several places the RFC _does_ describe character semantics, but that does not affect '*': Many URL schemes reserve certain characters for a special meaning: their appearance in the scheme-specific part of the URL has a designated semantics. If the character corresponding to an octet is reserved in a scheme, the octet must be encoded. The characters ";", "/", "?", ":", "@", "=" and "&" are the characters which may be reserved for special meaning within a scheme. No other characters may be reserved within a scheme. These characters are used in various schemes to distinguish different elements of the URL, e.g. query elements in HTTP URLs. Similarly, the RFC does not prescribe the use of '.' as path element to refer to the current directory - but '.' is a safe character, so URL schemes can safely use '.' that way. Same arguments hold for '*', IMHO.
So, please raise your voice now or hold your peace for evermore!
Raised ;-)
Back to square one we are, young Dutchman ;-)
Thilo
PS.: sorry for this biased mail ;-) Sorry for this biased reply ;-)
hehe :-) Cheers, Andre. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.