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).