[SAGA-RG] Fwd (andre at merzky.net): Re: More confusion

[Thilo Kielmann]

All,

I did a global search for "wildcard" in the SAGA core spec.
The result is that we are having three places using wildcards:

1. attributes
2. logical directory (using both attribute and path wildcards)
3. namespace.directory, using path wildcards.


Attribute wildcards don't pose a problem (at least to me, or until
Ceriel will find one ;-)

The path wildcards from namespace.directory, however, do bring a problem,
in combination with URLs.


If I remember correctly, we switched from strings to URLs for a good reason.

URLs, however, do not allow for wildcards, according to RFC1738.
And the here mentioned query parts of URLs are for http only, and not for
files as we would need them here.
If we define some "URL with wildcards" that would no longer be URLs, so this
is no way to go.


Why do we want/need wildcards for?
The core spec writes about "shell wildcards", so we want to apply a single
operation to several namespace entries at a time.
(e.g.: move, copy, find,...)

This reminds me of bulk operations with SAGA tasks. But this also feels like
"overkill" for the use case of file wildcards.


My suggestion is thus to follow Ceriel (version 2):

On Thu, Nov 22, 2007 at 11:12:58AM +0100, Ceriel Jacobs wrote:
> 
> Another approach would be to have an explicit method to do wildcard expansion.
> For instance, in namespace.ns_directory:
> 
>        expand        (in string pattern,
>                       out array<saga::url> urls);
> 
> Here, the pattern only specifies the "path" part, but with wildcards (the directory
> implicitly specifies the rest of the url). I am not sure whether the resulting urls
> should be resolved with respect to the directory or not. I think not.

I think we need to spend some good thoughts on getting the parameters to this
call right (do we need a pattern to compose the URLs from the expanded 
patterns???)


Besides this "expand" method, we would have to change the relevant
namespace.directory methods to accept arrays of URLs instead of individual
URLs.




The other radical approach could be: remove file name wildcards alltogether...


More thoughts?


Thilo
-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/