that might be true but I’d need to hear from more people to justify creating two very similar URI types. Technically `file:` is just a string that the file system interpreter gives meaning to; the scheme of a URL can be any alphanumeric string. For example you could write a file manager which interprets "foo:" as a local address, or ignore the scheme entirely.
On Mon, Aug 21, 2017 at 11:23 AM, Félix Cloutier <felixclout...@icloud.com> wrote: > 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> > 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> 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>. >> >> 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 >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution