Lars T. Kyllingstad Wrote: > On Sun, 06 Mar 2011 16:49:59 -0500, Nick Sabalausky wrote: > > > "Lars T. Kyllingstad" <public@kyllingen.NOSPAMnet> wrote in message > > news:il09fp$2h5d$1...@digitalmars.com... > >> On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote: > >>> > >>> What about extending the notion of 'device' (see other post) to cover > >>> 'http://' and "ftp://";? > >>> Would it be complicated? > >> > >> I don't think std.path should handle general URIs. It should only have > >> to deal with the kind of paths you can pass to the functions in > >> std.file and std.stdio. > >> > >> > > If std.path doesn't handle uri's, then we'd need a whole other set of > > functions for dealing with uris. And at least a few of the functions > > would overlap. And then people who want to be able to handle both files > > and uris will want functions that will seamlessly handle either. So I > > think it really would be best to just bite the bullet and have std.path > > handle uri's. > > I am now certain that std.path should not give URIs any kind of special > treatment, for the simple reason that most URIs are also valid paths on > POSIX. Specifically, file and directory names may contain the ':' > character, and multiple consecutive slashes are treated as a single > slash. In other words, you can do this: > > mkdir http: > mkdir http://www.digitalmars.com > cd http://www.digitalmars.com > > That means std.path should treat "http:" as just another path component, > and it should treat "//" on equal footing with "/". This is how it's > done now, and it is how it should be. > > -Lars
Not quite sure it would be that easy. http://en.wikipedia.org/wiki/URI_scheme
