[Public response, by permission, to accidentally-private message.]

On 2/7/20 11:06 AM, John Cowan wrote:
> I made an earlier attempt to integrate URIs and pathnames into a single type, but since I don't think it's feasible to ask implementers to change their file operations to work with URIs as well, I don't think there's anything to be gained by such an integration.  The pathname component of a URI is similar to a relative pathname, but that's as far as it goes.
>
> When I start looking at URI libraries, I'll definitely look at Kawa's.

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.

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.
(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.
(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.)
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/