desktop provider (was "Re: abstract paths")

[Mark Thornton]

Alan Bateman wrote:
> Mark Thornton wrote:
>> I think there are instances of File such that
>>    new File(f.toString())
>> is not equal to the original file 'f' (and in fact doesn't work at 
>> all). JFileChooser can return such objects on Windows. These files 
>> represent paths based on locations like "My Documents". Windows has 
>> never defined a programmatic string form for these paths. It would be 
>> rather useful if we had a way to obtain such 'roots' as Paths (as the 
>> actual underlying location can vary; i.e. "My Documents" isn't always 
>> called that).
> Someday it would be great to have a "desktop provider" that uses the 
> shell API and handles the various desktop/shell concepts like this. It 
> would delegate to the default provider for actual access to the file 
> system. A desktop file system could treat these special shell folders 
> as root directories, it could handle short cuts, it could allow the 
> progress of copy/move operations to be monitored, map content types to 
> icons, etc. It would be great to find a volunteer for this.
>
> -Alan.
A related issue is finding suitable locations for log files, caches, 
general program data, etc. Many operating systems have standard 
locations for these purposes, but they differ from each other. This of 
course is also relevant for server applications. I have implemented 
something of this sort (a bit crude, Windows, Linux only).

Mark