From: joel de guzman (djowel_at_[hidden])
Date: 2002-01-28 20:13:40
----- Original Message -----
From: "Gustavo Guerra" :
> > I'll explain my suggestion again. Instead of manipulating native path
> > which will work on platform X and not on platform Y, nor Z, I suggest
> > using a common, more formal and extensive path akin to URIs. The client
> > sees this and works on this. Behind the scenes, as needed, this is
> > converted to and/or from the underlying native format. The client does
> > not care about this. This "common-resource-identifier" should be rich
> > enough to describe any file-path format in existence as well extensible
> > enough to accomodate any future path formats. Such a formal resource
> > identifier will alleviate the multitude-of-formats problem.
> > I know this involves more work, but it is all worth the effort, IMO.
> > --Joel
> But what's the problem with doing "just" a pathname library now, that
> successfully abstract the native pathnames from POSIX(Unix and new MacOS X),
> Windows and VMS (possibly others)? After that, we can do a CRI like you say
> on top of it, that would take advantage of those weird MacOS FSRef and so.
> Why complicate? There is enough complexity involved in making a pathname
> class already.
That's reasonable. After all URIs are based on POSIX paths anyway. What's
more important in my suggestion is standardize on something and do the
platform-mapping on the spot on demand. This is the key point in my suggestion.
What standard to use is secondary (and of course subject to debate :). The
important thing is that the client does not have to care about the details such
as "what separator do I use in this platform?", "is this legal in this context?"
"is it case sensitive here, how about there?" etc. The client has to learn just *one*
standard and this is mapped automatically behind the scenes on each platform
where the library is deployed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk