abstract paths

[Alan Bateman]

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.