So are you saying we need *three* distinct “URI” types for local-absolute, local-relative, and remote? That’s a lot of API surface to support.
On Tue, Aug 22, 2017 at 12:24 PM, Dave DeLong <[email protected]> wrote: > I completely agree. URL packs a lot of punch, but IMO it’s the wrong > abstraction for file system paths. > > I maintain an app that deals a *lot* with file system paths, and using > URL has always felt cumbersome, but String is the absolute wrong type to > use. Lately as I’ve been working on it, I’ve been experimenting with a > concrete “Path” type, similar to PathKit (https://github.com/kylef/ > PathKit/). Working in terms of AbsolutePath and RelativePath (what I’ve > been calling things) has been *extremely* refreshing, because it allows > me to better articulate the kind of data I’m dealing with. URL doesn’t > handle pure-relative paths very well, and it’s always a bit of a mystery > how resilient I need to be about checking .isFileURL or whatever. All the > extra properties (port, user, password, host) feel hugely unnecessary as > well. > > Dave > > On Aug 20, 2017, at 11:23 PM, Félix Cloutier via swift-evolution < > [email protected]> 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 < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
