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

[Andre Merzky]

Quoting [Thilo Kielmann] (Dec 02 2007):
> 
> All,
> 
> I did not receive any reply on our proposal for resolving the wildcards issue.
> 
> May I safely interpret the silence as agreement?

Sorry, I was slow in answering - but please see my other
mail.

Cheers, Andre.


> I hereby make this the "final call" for comments on this issue.
> 
> Please speak up now, or hold your piece forever!
> 
> 
> :-)
> 
> 
> Thilo
> 
> On Thu, Nov 29, 2007 at 03:36:41PM +0100, Thilo Kielmann wrote:
> > From: Thilo Kielmann <kielmann at cs.vu.nl>
> > To: Andre Merzky <andre at merzky.net>
> > Cc: Ceriel Jacobs <ceriel at cs.vu.nl>, Thilo Kielmann <kielmann at cs.vu.nl>,
> > 	SAGA RG <saga-rg at ogf.org>,
> > 	Hartmut Kaiser <hartmut.kaiser at gmail.com>
> > Subject: URLs and wildcards (was: More confusion)
> > 
> > Ceriel and I have been chatting about this issue, producing a proposal for
> > a solution.
> > 
> > Two observations (Thilo only) up front:
> > 
> > 1. wildcards are ONLY applicable to the methods copy, link, move, and remove
> >    in class ns_directory, and to nothing else in the whole name space package.
> > 
> > 2. In ns_directory, method list has a parameter pattern, while method find
> >    has name_pattern. This should both be "pattern". It refers to the same kind
> >    of thing.
> > 
> > Further thoughts about URLs and wildcards.
> > 
> > 3. In ns_directory, list and find with their "pattern" parameter actually
> >    refer to pathnames, relative to the current working directory (CWD).
> >    We should say that explicitly in the spec.
> > 
> > 4. URLs, according to the RFC do NOT provide wildcards for files.
> >    (Non-)options:
> > 
> >    a) add specific wildcards (like '*') to the URLs we use.
> >       This would not be corformant to the RFC, so it would no longer be URLs.
> >    b) "Use" the query mechanism for http to express wildcards for files.
> >       While possible "in theory" this would be far from obvious, so this would
> >       NOT be anything "simple" to use. (remember the "S" in SAGA)
> >    c) Wildcard characters could be brought into URLs by %-escape sequences.
> >       Argument as with query: non-intuitive, not simple for the user.
> > 
> >    Summary: we MUST NOT introduce file wildcards to URLs.
> > 
> > This leaves us (IOHO - Ceriel and me) with two possible options for wildcards
> > for namespace entries (as expressed for operations on ns_directories):
> > 
> > A. Have an additional method expand that takes a string parameter describing
> >    a pathname, relative to the CWD, (possibly) containing POSIX-style shell
> >    wildcards.
> >    expand() has an output parameter, an array of URLs, the expansion.
> > 
> >    In addition to expand(), we add versions of the methods 
> >    copy, link, move, and remove from ns_directory that accept arrays of URLs
> >    instead of single URLs. (If we do not add these versions, we force the
> >    users to resort to bulk execution of tasks for a simple thing like
> >    "remove *.doc")
> > 
> > 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.
> > 
> > 
> > Any opinions on the proposal of implementing solution B ???
> > 
> > 
> > Thilo
> > -- 
> > Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/
-- 
No trees were destroyed in the sending of this message, however,
a significant number of electrons were terribly inconvenienced.