There's no question that there's a lot in common between file: URLs and other URLs, but that hardly makes URLs better in the file: case.
I saw the enum. The problem remains that it's a common API principle to accept the broadest possible input. It's not fundamentally wrong to accept and resolve common URL types, as there's a ton of things that need to read documents from the Internet by design. However, if this is the default facility for file handling too, it invents either: A responsibility for API users to check that their URL is a file: URL; A responsibility for API authors to provide separate entry points for file URLs and remote URLs, and a responsibility for API users to use the right one. It would also add a category of errors to common filesystem operations: "can't do this because the URL is not a file: URL", and a category of questions that we arguably shouldn't need to ask ourselves. For instance, what is the correct result of glob()ing a file: URL pattern with a hash or a query string, should each element include that hash/query string too? Félix > Le 20 août 2017 à 23:33, Taylor Swift <kelvin1...@gmail.com> a écrit : > > I think that’s more a problem that lies in Foundation methods that take URLs > rather than the URLs themselves. A URL is a useful abstraction because it > contains a lot of common functionality between local file paths and internet > resources. For example, relative URI reference resolution. APIs which take > URLs as arguments should be responsible for ensuring that the URL’s schema is > a `file:`. The new URL type I’m writing actually makes the scheme an enum > with cases `.file`, `.http`, `.https`, `.ftp`, and `.data` to ease checking > this. > > On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier <felixclout...@icloud.com > <mailto:felixclout...@icloud.com>> wrote: > I'm not convinced that URLs are the appropriate abstraction for a file system > path. For the record, I'm not a fan of existing Foundation methods that > create objects from an URL. There is a useful and fundamental difference > between a local path and a remote path, and conflating the two has been a > security pain point in many languages and frameworks that allow it. Examples > include remote file inclusion in PHP and malicious doctypes in XML. Windows > also had its share of issues with UNC paths. > > Even when loading an arbitrary URL looks innocuous, many de-anonymizing hacks > work by causing a program to access an URL controlled by an attacker to make > it disclose the user's IP address or some other identifier. > > IMO, this justifies that there should be separate types to handle local and > remote resources, so that at least developers have to be explicit about > allowing remote resources. This makes a new URL type less necessary towards > supporting file I/O. > > Félix > >> Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> Okay so a few days ago there was a discussion >> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038923.html> >> about getting pure swift file system support into Foundation or another >> core library, and in my opinion, doing this requires a total overhaul of the >> `URL` type (which is currently little more than a wrapper for NSURL), so >> I’ve just started a pure Swift URL library project at >> <https://github.com/kelvin13/url <https://github.com/kelvin13/url>>. >> >> The library’s parsing and validation core (~1K loc pure swift) is already in >> place and functional; the goal is to eventually support all of the >> Foundation URL functionality. >> >> The new `URL` type is implemented as a value type with utf8 storage backed >> by an array buffer. The URLs are just 56 bytes long each, so they should be >> able to fit into cache lines. (NSURL by comparison is over 128 bytes in >> size; it’s only saved by the fact that the thing is passed as a reference >> type.) >> >> As I said, this is still really early on and not a mature library at all but >> everyone is invited to observe, provide feedback, or contribute! >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
