Thilo,
I did not receive any reply on our proposal for resolving the wildcards issue.
May I safely interpret the silence as agreement?
I hereby make this the "final call" for comments on this issue.
Please speak up now, or hold your piece forever!
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.
Comparing both options, Ceriel and myself are in favour of B. It comes with less methods and a simpler and more obvious-to-use interface.
A is a very indirect solution where a user first has to build a list of URLs from a wildcard string, and then has to pass this list of URLs to, e.g., copy. With B, the user can directly pass the wildcard string to, e.g., copy. The "trick" is that the string is restricted in its expressiveness, namely to pathnames relative to the CWD.
I agree B is the better way to handling things. But what's the rationale of the 'relative to the CWD' clause? Do you want to ensure the call can be completely handled by a single middleware (adaptor)? Wouldn't it be sufficient to require that wildcard characters are alowed only in the filename part of an otherwise well formed (perhaps partial) url? Regards Hartmut