Quoting [Thilo Kielmann] (Dec 12 2007):
On Tue, Dec 11, 2007 at 11:37:16PM +0100, Andre Merzky wrote:
From: Andre Merzky <andre@merzky.net> To: Shantenu Jha <sjha@cct.lsu.edu>, Thilo Kielmann <kielmann@cs.vu.nl> Subject: spec
[...]
So, I'll go ahead and submit the spec tomorrow, ok? :-)
Veto!!!
The spec is NOT OK as the wildcard thing is not resolved.
What's the solution???
Thilo
Ah, right, that one... That indeed needs resolving. I post this answer to the list again then. I guess its 'your' way (B), as there were two votes (Ceriel, Thilo) against one (me). Hartmut voted as well for your suggestion, but on a choice which did not include 'my' version (C). So, either we just go with B (which I don't like too much, but hey... ;-), or do another straw poll, which is boring. Not a win-win-situation IMHO :-P Ok, Proposal: I summarize the options and their pro and cons below, and you and all list members you has a chance to do the right thing and vote 'C' until tomorrow evening. If nothing happens, 'B' is the one we will use. 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. In both cases, wildcards for attribs, find etc (which all are string patterns) are unaffected. In both cases, wildcards should only be allowed in the path element elements of the URLs (i.e. not in the scheme, host, port, auth or query elements of the URL). 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. So, please raise your voice now or hold your peace for evermore! Cheers, Andre. PS.: sorry for this biased mail ;-) -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.