[SAGA-RG] spec

[Andre Merzky]

Quoting [Thilo Kielmann] (Dec 13 2007):
> 
> On Wed, Dec 12, 2007 at 09:23:41PM +0100, Andre Merzky wrote:
> > Options:
> > 
> >  (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
> > 
> >      Correction 1: also for permission_allow/permission_deny
> >      Correction 2: remove the limitation to relative paths
> > 
> > 
> >  (C) Allow '*' as wildcard in URLs (in the path element part).
> >      Add an expand method for more elaborate wildcard
> >      expansion, which accepts a string and returns a list of
> >      URLs.  Looping is in user space.
> > 
> 
> > I am not sure if we came to a closure on 'Correction 2', but
> > I think that Ceriels answer ("if you need abs paths, then do
> > a 'cd()' to somewhere where you can use rel paths") is a
> > rather inelegant workaround for a limitation which is not
> > too well motivated, IMHO.
> 
> The motivation for relative paths is: an absoute path immediately
> becomes a URL, (well, a URL-shaped string)

Why is that?  

  tmp/data.bin   <-- relative
  /tmp/data.bin  <-- absolute

  http://localhost/tmp/data.bin   <-- relative
  http://localhost//tmp/data.bin  <-- absolute

There is no real difference here in appearance, apart from
the slash leading the path element of the URL.  I say its
confusing to allow one form but not the other.


> where we cannot have wildcards.
> This would LOOK LIKE allowing both strings and URLs for abolute paths,
> utmost confusing to the user (because of the subtle differences in acceptable
> syntax although both LOOK pretty much identical).
> It also feels like feature bloat.
> 
> I still consider 'C' a bloody hack because even the '*' violates
> URL syntax according to the RFC.

No, it does not.  '*' is explicitely a valid character which
can be used w/o encoding in the path element of any URL (in
fact in any other element, too).  See second to last
paragraph in 2.2 on http://www.ietf.org/rfc/rfc1738.txt:


   Thus, only alphanumerics, the special characters
   "$-_.+!*'(),", and reserved characters used for their
   reserved purposes may be used unencoded within a URL.

Sorry Thilo, but I think thats pretty clear.  The RFC does
not prescribe the interpretation of '*' as wildcard, thats
true.  In several places the RFC _does_ describe character
semantics, but that does not affect '*':

    Many URL schemes reserve certain characters for a
    special meaning: their appearance in the scheme-specific
    part of the URL has a designated semantics. If the
    character corresponding to an octet is reserved in a
    scheme, the octet must be encoded.  The characters ";",
    "/", "?", ":", "@", "=" and "&" are the characters which
    may be reserved for special meaning within a scheme. No
    other characters may be reserved within a scheme.

These characters are used in various schemes to distinguish
different elements of the URL, e.g. query elements in HTTP
URLs.  


Similarly, the RFC does not prescribe the use of '.' as path
element to refer to the current directory - but '.' is a
safe character, so URL schemes can safely use '.' that way.
Same arguments hold for '*', IMHO.


> > So, please raise your voice now or hold your peace for
> > evermore!
> 
> Raised ;-)

Back to square one we are, young Dutchman ;-)


> Thilo
> 
> > PS.: sorry for this biased mail ;-)
> Sorry for this biased reply ;-)

hehe :-)

Cheers, Andre.


-- 
No trees were destroyed in the sending of this message, however,
a significant number of electrons were terribly inconvenienced.