Re: the first version of abstract path manipulation c lass (interface)

From: ilv2fly2001 (mcr_at_[hidden])
Date: 2002-01-30 09:54:09

--- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> From:	John Maddock [SMTP:John_Maddock_at_c...]
> > 
> > BTW the situation is much more complex that one would think -
> > case sensitivity is a property of the pathname itself, and not
> > the platform on which it is running.
> > 
> > Consider that NT does support case sensitive filesystems - in
> > which case the case sensitivity is dependent upon the drivename
> > (see GetVolumeInformation).  However on unix systems you can
> > mount a case insensitive filesystems within a case sensitive one,
> > throw in symbolic links and the whether comparison is case
> > sensitive changes with each part of the pathname: so
> > with /foo/bar the foo part may be case sensitive and the bar part
> > case insensitive.
> 
> Wow!  You're right.  I hadn't thought of that.  I don't know that
> there is any good way to deal with this.  I shouldn't think we'd
> want a pathname manipulation class to be accessing the filesystem
> to check on the case sensitivity of each path component; that will
> get pretty nasty.
> 
> I'd be inclined to say that you create an object to manipulate a
> pathname with or without case sensitivity, and leave it to the
> programmer to decide how many such objects to use and in what
> combination.  IOW, the programmer could check the filesystem for
> case sensitivity, create pathname objects for each portion of the
> path where that sensitivity differs, and manipulate that set of
> objects as a logical whole.  That puts the onus on the programmer
> and not the pathname class.
> 
> Perhaps that means we need a simpler, lower level class that
> manipulates a pathname or some portion of one, using a single case
> sensitivity/filesystem policy, and another, higher level class,
> that aggregates the simpler objects to create a logical pathname
> object that spans filesystems.
>

Perhaps what is needed is a container of path components, where each 
of the seperate components maintains its own set of properties or 
traits, and the input and output of the container contents is handled 
transparently through a collection of facets.

This way, the internal representation of a path is standard across 
all platforms, and its the task of the facets associated with a given 
platform to decide if its possible to legally represent either the 
passed in user value or the extracted value of pathname. The facets 
would also be tasked with normalizing the values as they see them so 
for instance, on Win32 forward slashed become backward slashes.

Extending pathname to support URI and all its related schemes 
(URN/URL/...) would simply be a matter of adding the prerequisite 
facets and modifying the traits associated with the newly supported 
individual pathname components.

These facets could also have set defaults making it possible to 
emulate an unavailable system interface (posix/vax/...) on say a mac 
for internal application use even though such a representation would 
be gibberish to the real underlying platform.

This would tend to make pathname's (the component container) 
interface strictly a positional one like std::string I think.

In instantiating a pathname, one would then assign the desired 
platform facet to it.

Thoughts?