Hi Thilo, all, Quoting [Thilo Kielmann] (Dec 03 2007):
Further thoughts about URLs and wildcards.
Another take on "why NOT having wildcards in URLs denoting files and directories":
1. the reason for having wildcards in the first place is to have something with the "look and feel" of POSIX shell wildcards in SAGA calls.
IMHO, the reason was to simplify calls and usage, and we went for posix shell wildcards because they are known and simple...
==> everything that contradicts this look-and-feel is to be ruled OUT
Hmm, I am not sure about that. Why? You know, I am the first one to argue about staying close to posix, right? :-) But staying simple in the API is more important IMHO.
[...]
2. when using URLs we MUST conform to RFC1738
Right, we all agree by now that, apart from '*', other wildcard chars are invalid characters.
aside: the use of the '*' in the NEWS scheme is irrelevant here because this only applies to NNTP news, NOT to files or directories
NNTP is just an example. The point is that you can legally use '*' in URLs, and we are free to interprete it as a wildcard.
We could, however, restrict ourselves to the '*' wildcard only, but this is a very limited form of wildcards, although freqeuntly used, not really worth being called "POSIX shell wildcards".
Right, this would not be posix wildcard, but just the '*' wildcard.
Hmm, a mail from me seem to have gone astray? A while ago in this thread I wrote:
So, unless my interpretation is wrong, I'd say that '*' is explicitely allowed as wildcards.
Your interpretation IS wrong (see above, this is ONLY applicable to NNTP)
Hmm, I may very well be wrong, but can you please explain why? If '*' is a valid character, and, for example by NNTP is used as wildcard, why cannot '*' be used as wildcard elsewhere?
B: why the limitation to relative path names?
Idea: keep URLs for absolute, global identifiers. Have strings with POSIX shell wildcards as local names, relative to the directory the operation is working on.
Yes, got that - but that would disable rm /tmp/* for no good reason, wouldn't it? I would understand if you'd say that the string can only contain path elements of an URL or something like that. Or, better IMHO, that only the path element can contain wildcards?
For C speaks that '*' is, probably, the most commonly used wildcard - so using that in the standard URL calls would help a lot. As for the other wildcards, a detour via expand does not sound too bad anymore...
It leaves us wild the feelilng of a "hack" while we could also have a clean solution: URLs without and relative strings with wildcards.
Its a matter of taste as usual I guess. At the moment, I would very much prefer to change (simplify!) the definition of wildcards in the spec it just seems simplier(!) to me. I would also be happy by now with just using '*', and not having full posix wildcards (thus no need for expand()). You/Ceriel seem to prefer the other way around, for basically the same reason, simplicity ;-) Andre. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.