Per Bothner scripsit:

> The support for "wild" components adds some extra power, but it adds a
> lot of complexity.  And it's still not very general - it only supports
> a very restricted form of globbing.  And at the cost of not being able
> to map generally to URIs.  And how does someone make use of a pathname
> with a wild component?  I recommend dropping the feature.

You're right.  When CL was defined, in the far more heterogeneous file
system world, "wild" probably looked like the simplest thing that could
possibly work.  Now we have a universal text representation of globs.

> Similarly version numbers: Nobody uses them and most people don't
> know what they are.  Many (most?) of us seem to believe that version
> numbers were a mistake for library names; I think it would be a mistake
> to standardize them for pathnames.

I only kept versions in because CL has them (again, reflecting the
influence of now-dead file systems) and because Emacs, which is heavily
used by Schemers and was born in that world, goes to the trouble of
emulating them.  I've removed them tentatively, as they are rather
complicated.

> If think having both pathname-query-as-string and pathname-query
> is awkward.  I also think defining a the query as either a string
> or an alist is awkward - just define it as a string, and add some
> extra utility routines: either a routine that takes a query string
> and yields an alist; or a routine that takes a pathname and returns
> the query string as an alist; or a routine that takes a pathname and
> a query key and returns the corresponding query value.

I agree, and I now provide the second option as `pathname-query->alist`.

> I'm not sure the options parameter in various functions is needed
> or desirable.  We already got rid of 'version.  The use of 'windows
> seems inconvenient: You want 'windows to be the default on Windows
> but only on Windows.

I've done this in a different way.  Discussions on uri@w3c.org have
convinced me that using the host component for UNC names is a bad idea, so
I've added `unc` as a third option for the car of the directory component.
There is also now a SRFI 39 parameter giving the pathname syntax as either
`posix` or `windows`, which controls how parsing is done.  Its initial
value is implementation-dependent.  I have also dropped support for
Berkeley-style host:pathname syntax, so the options list is no more.

> Note the concept of "directory" isn't really well-defined in the
> URI world.  Informally, a directory may be a path/URI that ends in
> "/".  However, a web server will usually just ignore the final slash
> and this not distinguish between files and directories.

True.  Everything up to and including the final (back)slash is parsed
as a directory, so the file and type components may be #f in that case.

> In my API I went a slightly different way: Basically a pathname is an
> object that is isomorphic to a URI.  The various library routines are
> defined as string operations: They are useful and meaningful when the
> strings are interpreted as filenames and URIs, but the *definition*
> of the operations should independent of any underlying file or server
> objects.

That's my intention too.

> merge-pathnames should be defined so it is compatible with the URI
> "resolve" operations.

I've dropped query merging, but I need to think about this further.

--
John Cowan   cowan@ccil.org    http://ccil.org/~cowan
I am he that buries his friends alive and drowns them and draws them
alive again from the water. I came from the end of a bag, but no bag
went over me.  I am the friend of bears and the guest of eagles. I am
Ringwinner and Luckwearer; and I am Barrel-rider.  --Bilbo to Smaug

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports