> 
> Oh, don't get me wrong, I think URIs are great. I just don't think they
> should be the low-level mechanism for accessing the file system. I'll
> grant that file URIs are an improvement over the current use of
> platform-specific strings. They'd give us a standard string format. But
> at the end of the day they're still strings, and we'll still have the
> awkward code that Tim was complaining about.

Actually they don't have to be strings. A URI class could be the best
representation. I posted an email that had the sections there are in a URI.
So we can use URI instances between systems especially if they represent
relative paths. I do realise there are problems with some systems that can't
be translated.

Ok, this might make my position a bit clearer. I am thinking laterally on
this.

Streams are the main part of file access most people want. However we know
that there are other things like iterating through a directory, file
permissions etc.
What *I* want :) is ease of use. What other people want is power use.
So the Objects that I can see (maybe too simply perhaps) are:
Streams
Resources
URIs

A Resource is an object that can be returned by processing a valid URI. A
URI can be created from a String or programmatically.
URIs have the concept of Schemes which are ways of getting a Resource.
Schemes can be registered which will create an instance of a particular
Resource on demand.
A Resource could be a file, directory, MacintoshFile, HttpFile,
AcornDirectory, TcpStream, maybe ZipFile, SMBMount.
The Resource would be the bridge object to a particular os dependent
"resource" be that a file, tcp socket. In fact you could have Resources
chained together i.e. a zip encoded stream on another resource.
Nothing stops the power users from creating Resources manually to get to the
internals.
URI gives the portability, Resource gives the control.
For example
I have a Win32 machine but I have copied a file from a unix system so my
default resource for opening a file doesn't handle the end of line
characters properly. So what I do is ask the Win32FileResource to answer a
UnixFileResource opened on it.
Now I can read the file by lines and have it work properly.
I finish my debugging and put the image back on the unix server to run.
Because I used relative paths in my URIs (because the bridges are removed
during shutdown) my directory structure is the same and the correct bridges
are created for the os (assuming the files are there of course :).

It would sorta be like Morphic for files.