abstract paths

[Alan Bateman]

Alan Snyder wrote:
> It is not obvious to me that abstract pathnames are meaningful only 
> for relative path names. No argument has been made to justify this claim.
Perhaps I mis-understand your original mail, but weren't you asking for 
a way to represent a path that wasn't tied to a file system or provider? 
If so, then any path with a root component (say "C:" or "D:\" or 
"\\server\share" or "disk$:" for example) isn't going to readily 
translate between providers or into a provider-independent form that you 
require. The other complication is of course that you may loose the 
internal representation (many file systems use bytes rather than Unicode 
strings for example).

>
> Two possible counterexamples:
>
> 1. A backup program that creates a catalog of a snapshot of a file 
> system could record absolute paths in the catalog.
I don't see any issue here.

>
> 2. Copying a file from one file system to another could use the same 
> absolute path for both the source and the destination. A current 
> example of copying between two file systems (providers) would be 
> mirroring files onto an FTP host.
The copyTo method can be used to copy between providers. The only 
restriction is that some of the meta data may not be copied (because it 
don't make sense to the target file system). You can try this out now 
with the zip provider to copy files from a zip file system to the 
default file system for example. The source and target can be absolute 
paths. When you copy from /dir/foo to C:\dir\foo then the paths aren't 
the same though (meaning they aren't equal but the String representation 
of the names may be equal).

>
> (I believe that incremental backup and FTP mirroring are basically 
> equivalent and can be implemented using a common core.)
>
> (Perhaps there is a question of how seriously to take the possibility 
> of multiple file system providers. 
We do expect there will be multiple providers available although the 
number will likely be small. Today we don't have a good solution on how 
to translate paths between providers (except for Strings which you can 
use now).

> One direction is to assume that the native file system provider will 
> be the interface of choice to all file systems. However, since the API 
> allows multiple providers, I'm assuming this feature is intended to be 
> supported and useful.)
>
> I understand that an abstract pathname can be represented as a list of 
> strings, and making the conversion easier is a good idea.
It may be "good enough" for most cases but in the longer term we may 
need to allow for other representations (bytes in particulars).

>
> I also understand that there is nothing to stop me from creating my 
> own abstract path class (which I have done already). However, since my 
> abstract path class is so close to (a subset of) the Path class in 
> this project, it seems odd not to be able to use a standard class for 
> this purpose.
>
> Is there an objection other than a desire to limit change to the API? 
> Is there a document that explains the design rationale?
Could you expand a bit further on what your abstract path is? (from your 
original mail I gathered it's a sequence of names but perhaps there is 
more).

-Alan.