>From: David Abrahams [mailto:dave@boost-consulting.com]
>>>     portable_path("/foo/bar") <- throws on Windows
>>
>> Not sure why this would throw, what is the purpose of portable_path?
>> "/foo/bar" is perfectly reasonable on Windows.
>
>It's perfectly reasonable but it doesn't have a portable meaning.  It
>is a relative path w.r.t. the drive of the current directory.

Almost all paths are relative w.r.t. something, the current users filesystem mapping, the computer, the network. I don't see how leaving out the drive makes it less portable then leaving out the computer name.

>>>This is also a way we could solve the whole problem of absolute paths.
>>>It's clear that "/foo" isn't an absolute native windows path.
>>
>> This is not at all clear. I have and will contain to argue that "/foo" is an
>> absolute windows path, since it does not respect the current
>> directory.
>
>If you define anything that is not relative to the current directory
>as absolute, maybe you can say that.  It seems perverse to say that a
>path which is _relative_ to something other than the machine in use
>is absolute, though.
>
>> Also very important to me, this goes well with the URI definitions
>> of absolute and relative
>
>I'm pretty sure this is an illusion!  URIs don't have a notion of
>"current drive" do they?

URIs are a multirooted system that have the semantics I'm advocating for file paths. To make an example, if you are looking at "http://localhost/somedir/index.html" it might have an absolute (as defined by the RFCs) href of "/foo/bar" that takes you to "http://localhost/foo/bar" and another relative (again, as defined by the RFCs) href of "foo/bar" that takes you to "http://localhost/somedir/foo/bar". This is because paths, relative or absolute, are with respect to the authority (localhost in this case).

If you can give me an example of a multirooted system that refers to paths that are absolute with respect to the current directory as relative I'd be interested, my multirooted experience is limited to CP/M, DOS, AmigaOS, OS/2, Windows, and URLs. I don't have any big system experience with them.

>> and it would be nice if the path class could support full URIs.
>
>Are we talking about native or "portable" representation now?
>There's no reason they couldn't support full URIs in their portable
>representation.  It's just a question of how that gets mapped onto
>the native filesystem.

What I'm thinking of may not be in the scope of the filesystem library, I'd like a path class that could directly manipulate URLs; authoritys, fragments, options and all. Direct use of "file:/.." URLs would be good too.

Glen