abstract paths

[Alan Snyder]

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.

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.

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.

(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. 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.

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?




On Jul 14, 2008, at 4:41 AM, Alan Bateman wrote:

> Alan Snyder wrote:
>> Thanks to the article by Elliotte Harold, I have become aware of  
>> this work. I want to say that it is long overdue and will be much  
>> appreciated.
>>
>> I want to make a pitch for supporting fully abstract paths, that  
>> is, paths that are not bound to any file system or file system  
>> implementation. A fully abstract path is simply a sequence of  
>> names. Before it can be used to access a resource, it must be  
>> presented to a file system (which might convert it to a bound path  
>> as in the current design).
> As Mark suggests, this probably only makes sense for paths that  
> don't have a root component. In that case, the path is simply a  
> sequence of names. In that case, the only awkward issue is how to  
> represent those names. If you can live with Strings (recalling that  
> converting from the platform representation to String may be lossy,  
> at least on platforms where representation is bytes) then  
> List<String> or String[], as Mark suggests, might be okay. Since  
> Path already implements Iterable<Path> and defines the  
> resolve(String) method it means you should be able to try this out  
> now (yes, it would be a bit inefficient but if this is generally  
> useful then we could define methods to import/export as a sequence  
> of names).
>>
>> Fully abstract paths can be useful whenever you are performing  
>> cross file system operations, such as mirroring. The same relative  
>> fully abstract path can be presented to two file systems to access  
>> resources that correspond by name. Fully abstract paths could also  
>> be used in a catalog (as might be created by a backup program),  
>> which stores metadata but does not contain the actual files.
> I'm interested in hearing about the mirroring - are you thinking  
> about mirroring directory structures between file systems associated  
> with different providers?
>
> -Alan.