Firstly I didn't continue this discussion because of problems with FileURL
(as I have only started looking at it), I got sidetracked into URIs.

What I would like (other than some feedback, last time the silence was
deafening :) is to not have to bother with Streams and Files unless I really
need to.

I am proposing a "Resource" which is created in several different ways
including via URIs (ah there they are) or programmatically. Here is a
partial list of what I see as Resources:
Images (jpeg, pgm, gif, bmp )
Audio (mp3, wav, pcm, ogg)
Video (mpeg, DivX )
Files (text, binary, mac, unix, acorn, win32, pda, xml)
FileDirectories
Utilities (zip, encryption)
Protocols (http, ftp, sockets)

My grouping might not be right but the principle is sound.

Some points in no particular order:
The idea would be to have stream creators which are the link to the outside
world and stream consumers which are the layers used to decode the stream
into the final object required. Really a Resource is a translator.

Resources would return a decoded object. Files would return a stream, file
directories would return a collection of FileResources or URIs, JPEGResource
would return a Form or collection of Forms (if there is more than one image
in a file), Sound resources return a SoundBuffer, etc.

URIs would be used for creation of a URI object which any resource should be
able to create itself from. So if I want to create a JPEGResource from a
file, I should be able to say 
"JPEGResource onURI: (URI fromString: 'file:///dir1/dir2/file1.jpg' ).
Here are some variations on this:
JPEGResource onURI: (URI fromString: './file1.jpg' ) (uses imagePath to
create a base URI)
JPEGResource onFile: (FileResource onURI: (URI fromString:
'file://localhost/dir1/dir2/file1.jpg' ))

In all cases above I would be returned a JPEGResource linked to a
FileResource linked to a Win32FileResource linked to a URI.
JPEGResource asks for a Stream from the source resource to decode itself,
that's all it cares about.

The query part of a URI is only relevant for the "resource" part of the
scheme. The fragment part is only relevant for the returned data.
So I can have a statement "(URI fromString:
'./file1.txt?read&write#seek=1024" which returns me an opened text file
which is readable and writeable, also the stream has been advanced 1024
"things".

> I find them weird because they are so poorly defined IMHO. And since
> file paths are so clearly not portable over different filesystems
> (volume names, filename lengths, allowed chars etc etc).
There is no system that will handle file portability over many systems
unless you go to the least common denominator. I don't think many people
would advocate that file names in Squeak must be less than 14 characters and
guess what, they are not now! So we *already* have file portability
problems. URIs IMHO would reduce (but not remove) some of the existing
problems. For example why does the 3.7a image have a file in Mac directory
format in it? I don't have a Mac so that file in not portable at all and it
is tricky to translate the file name to a Win32 file name (or Unix,etc). If
that was a URI, I wouldn't care or know. I could just use it and as long as
the resource is in the place the URI points to, it will work.

Resources would be temporary, URI would be permanent (I mean Resources would
be closed on image shutdown and URIs wouldn't).

This is some food for thought. The more I think about Resources the more
they make a LOT more sense than mucking around in streams directly. I mean
wouldn't you want to be able to treat Zip files the same way as directories?
They have a directory structure and they handle files in a similar way. I
could then have a Zip file which has all my data for my application, I can
test it with physical files in a physical directory and for production move
all the files to a Zip file, change my application's base URI, done!

Also I think that nearly everything we need to make this work is already in
the image, Resources are a different way of putting the pieces together.

Any thoughts?
Russell