Re: [boost] Thought on paths

From: Ken Hagan (k.hagan_at_[hidden])
Date: 2002-01-28 08:05:35

----- Original Message ----- 
From: "Daryle Walker" <darylew_at_[hidden]>
Subject: [boost] Thought on paths

> So the path objects shouldn't store the path as a single string
> that needs parsing, but as a list of intermediate directory
> names, the final object, and possibly the volume designator and
> other data.

We still need to provide some way for a user to type in a path and
have the program derive other valid and related paths from it.
I assume the user input will be plain text, so this only really
changes when we do the parsing. An early parse might allow more
re-use within the library code, but it won't change the interface.

I think the discussion so far has shown that we are a long way
from an interface that makes sense on non-UNIX systems. (I consider
Windows to be unix-like.)

That interface will presumably deal with objects (files) and
containers (directories, volumes, machine names). An interface
this abstract probably handles URLs just as easily as traditional
paths.

The interface might also recognise the concept of a file extension
or file type, but at least on Windows and the Mac, the file type
is not a completely free variable for programmers to set as they
choose.

For the containers, we'll want some way of enumerating all the
contained items that match a template, such as "*.c". We might
be able to assume that the template is provided by the user, or
is configured separately for each platform. If not, we run into
the non-portability of file extensions again. Closer to the root
of the hierarchy, enumeration might not be possible. (For example,
enumerate http://*/ if you dare!)

We'll need to recognise that remote volumes (either with an explicit
machine name or accessed through a mapped drive letter or mount
point) are potentially much slower than local ones, so programs will
want some way of telling the difference.

We'll also want some way of identifying links, either symbolic or
hard, or else we can't write utility programs that don't fall
into infinite loops.

Finally we'll need some way of mutating existing file names. For
example, if I create an HTML version of a C file, the natural name
on some systems is "file.c.html", but on others it is "file.htm".