[SAGA-RG] URLs and wildcards (was: More confusion)

[Andre Merzky]

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.