On Sat, Feb 8, 2020 at 2:33 AM Per Bothner <xxxxxx@bothner.com> wrote:
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 think there are two issues here: parsing and the abstract model.  There is no doubt that one needs multiple different parsers.  For example (all strings are raw), "foo\bar\baz" represents a relative path with a single element to a Posix parser, but a three-part path to a Windows parser.  The string "c://bar" will be interpreted differently by a Posix, a Windows, and a URI parser.  For other obsolete native pathname interpretations (CLtL2 gives syntaxes for five PDP-10 operating systems plus VMS), other parsers would be required

Furthermore, the underlying abstract models don't overlap all that much:

Posix:  Relative/absolute flag, sequence of file names.

Windows:  Host, device, relative/absolute flag, sequence of file names.

CL: Host, device, relative/absolute flag, sequence of directory names, file name, file type/extension, version.

Generic URI: Scheme, rest-of-URI where:
  rest-of-uri may be authority, host, port, sequence of file names, query, fragment where
    authority may be username, password (deprecated), host and
    query may be a sequence of key-value pairs.

So a full superset model requires the following abstract fields, some of which overlap: scheme, rest-of-URI, authority, username, password, host, device, port, relative/absolute flag, sequence of file names, sequence of directory names, file name, file type/extension, version, raw query, query a-list, fragment.

I believe it is fairly evident that this is far more complex than necessary for solving any particular problem.  Unifying Posix and Windows filepath models is plausible: the Windows host and device fields are mutually exclusive and on Posix they are null.  My library also allows unparsing a path object into a file: URI.  But I just can't see going beyond that.

 John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
               Si hoc legere scis, nimium eruditionis habes.