Re: SRFI 170: 270 days John Cowan (06 Feb 2020 03:52 UTC)
Re: SRFI 170: 270 days Arthur A. Gleckler (06 Feb 2020 05:51 UTC)
CWD and other unresolved issues Lassi Kortela (07 Feb 2020 15:34 UTC)
Re: CWD and other unresolved issues John Cowan (07 Feb 2020 15:42 UTC)
Re: CWD and other unresolved issues Lassi Kortela (07 Feb 2020 15:47 UTC)
Re: CWD and other unresolved issues John Cowan (07 Feb 2020 18:04 UTC)
Re: CWD and other unresolved issues Arthur A. Gleckler (07 Feb 2020 18:48 UTC)
Re: CWD and other unresolved issues Per Bothner (07 Feb 2020 18:57 UTC)
(missing)
Re: CWD and other unresolved issues Per Bothner (08 Feb 2020 07:33 UTC)
Pathnames and URIs Lassi Kortela (08 Feb 2020 09:12 UTC)
Re: Pathnames and URIs Lassi Kortela (08 Feb 2020 09:20 UTC)
Re: CWD and other unresolved issues John Cowan (08 Feb 2020 18:58 UTC)
Pathname representations Lassi Kortela (07 Feb 2020 22:19 UTC)
Re: Pathname representations Per Bothner (07 Feb 2020 22:32 UTC)
Re: Pathname representations Arthur A. Gleckler (07 Feb 2020 22:36 UTC)
Re: Pathname representations Lassi Kortela (07 Feb 2020 22:50 UTC)
Re: Pathname representations John Cowan (08 Feb 2020 07:02 UTC)
Re: CWD and other unresolved issues John Cowan (07 Feb 2020 19:01 UTC)
Re: CWD and other unresolved issues Arthur A. Gleckler (07 Feb 2020 19:20 UTC)
Re: CWD and other unresolved issues Marc Feeley (07 Feb 2020 20:15 UTC)

Pathnames and URIs Lassi Kortela 08 Feb 2020 09:12 UTC

> For an implementation that supports URI/URLs (and opening ports from URLs),
> I think it is better if the URL API is similar to filename URI.
> For example, I think it makes sense to use the same API to extract
> parts from a file: URL and from a filename object - in an implementation
> supports working with URLs.

It's probably true that the APIs should at least be symmetrical.

> I see good reasons why the filename API should be designed to be a subset
> of a more general API that supports URLs, even for implementations
> that only support the former.
> (1) It provides a path (so to speak) for an implementation without URLs
> to be extended to one that supports URLs.

This is good.

> (2) It allows code to be more portable: If a program or library works
> with namesnames portably, it will probably also worth with URLs in
> an implementation that supports them, with little or no changes needed.
> (3) It seems inelegant to have to use different APIs if working with
> a filename vs working with a file: URL.
>
> Note these benefits do not require filepath or URLs as distinct types:
> You can generally just work with strings, and distinguish them by syntax.

There are important security and performance implications to opening a
URI in place of a file. I've found generic URI opening useful mainly in
simple scripts. If any `open` call in a complex application can turn
into a `open-uri`, a security audit is difficult.

> (Though there are some corner cases, especially if you support both
> relative filenames and relative URIs: You can't syntactically distinguish
> them, which could be an issue in the case of special characters, such as
> '%':
> They should be literal in filenames, and escapes in URIs.)

In the case of URIs, it may even be best to have different APIs for
different URI schemes: http, ftp, mailto... There are subtle differences
in how seemingly similar cases are treated, and implementations don't
always follow the same standards (when they follow any at all).