Re: [boost] Re: the first version of abstract path manipulation class (interface)

From: joel de guzman (djowel_at_[hidden])
Date: 2002-01-29 15:51:57

----- Original Message ----- 
From: "Beman Dawes" :

> At 11:49 PM 1/27/2002, joel de guzman wrote:
>  >
>  >----- Original Message -----
>  >From: "Jesse Jones" :
>  >
>  >>
>  >> Aren't paths an implementation detail? What about OS's now and in the
>  >> future that deprecate paths? I don't see why we can't create a higher
>  >> level class that works just as well as a path-centric class, but also
>  >> works well on the Mac OS.
>  >
>  >Exactly! That's why I suggested conversion to and from a standard well
>  >defined format such as a URI (Universal Resource Identifier).
> 
> That makes a lot of sense to me.  I started to look at 
> http://www.w3.org/Addressing/ to get an idea of what was involved, but 
> quickly got lost in the details.  Which scheme are you suggesting? 
> http://www.ietf.org/rfc/rfc2396.txt perhaps?

Yes. RFC2396. I am not sure though,as Darin noted, if this is rich
enough to encode all the intricacies of file-paths. When I implemented
the URI-as-path scheme a few years ago, I did not take into account
the Mac's volume ambiguity. Nevertheless, what I really meant was
that a nice well defined standard might be a good starting point.
There are quite some advances now regarding "resource addressing"
that goes beyond files. Many people (W3C for instance) have invested
lots of time and devotion in this area. I find it unwise not to leverage
this considering the enormous amount of information we have out there.

Anyway, at the very least, a "resource identifier" is a better (more generic)
name than path or filename.

--Joel