On Apr 22, 2004, at 7:00 PM, Russell Penney wrote:

> Hmmmm I don't think I agree. I think a *VERSION* of the URI spec would 
> be
> the best way of giving platform independence with the benefit of being 
> able
> to handle http, ftp, files, etc in a transparent way.

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.

> If you look at the URI spec it is very simple. Really the base URI 
> spec only
> specifies a few things, a character set that is valid (with the 
> ability to
> escape reserved characters), a scheme (file, http, ftp), an authority
> (usually host name), and a path.
>
> I want to basically say (syntax is just an example):
> f := ( File fromURI: 'file:///blah/foo/myfile.txt' ).
> f bytes (or size).
> f isReadable.
> f isWriteable.
> f isExecutable.
> f makeWritableByAnyone.
> f openReadOnly.
>
> Where f is a File object or a Directory object. These objects talk via 
> a
> Bridge object to the OS.
> Now change the initial string name to be an http address. Everything 
> should
> keep working with NO changes (well as little as possible). Same File or
> Directory object is returned (or maybe a FtpFile ).

URIs don't have to be fundamental for the above scenario to work. 
Naturally there should be a way of resolving a file URI to an actual 
file, and it would probably be feasible to have WebDavPeer and 
FtpFilePeer for dealing with remote files.

Colin