Patrick Mauritz said

<snip>

> so what's with a file called
>  - file.zip#first_example.txt
A file called "first_example.txt" from the zip file file.zip

>  - a reiserfs4 file file.zip, with extended attributes
>    (which you get at file.zip/attribute)
Sorry but I am doing a system which is fairly lowest common denominator. For
advanced attributes you would access the raw object directly.
Resources are not to replace low level file access but to make access a
simpler experience.

>  - file1.zip#file2.zip#file3.zip/file4.zip#finalfile.txt
LOL ok you have a file "file1.zip" which has "file2.zip" in it, which has a
directory file3.zip and in that directory is "file4.zip". Inside 'file4.zip"
is a file "finalfile.txt"
I would expect that if you had a URI containing the weird fragment, then if
you ask for the resource you would get "finalfile.txt". Fragments are parsed
by the data returned so it must be relevant to that data. Each file type
could have its own fragment format

> 
> of course, that's a bit far-fetched, but seamless jumping between
> directory
> systems doesn't necessarily make things easier
Not the idea. The idea is that a Resource returns a decoded object. Well you
say, they do that already. Of course they do BUT they don't do it in a
consistent way. Images are ok because ImageReadWriter handles the access,
audio files are different, zip file are different again, etc.
>From a new user point of view and from the viewpoint that Squeak is hailed
as "A multimedia environment", this is too complex.

I want to be able to specify a file "./file.jpg" and get a Form back (or
some other object). 
'./file.jpg' asAbsoluteURI contents
'./file.jpg' asAbsoluteURI image

Resources are not designed to get low level access or manipulate raw data
but to provide a high level access to all the different media types in
Squeak. Also to make it easy to add a new file type into the framework.

> 
> maybe it would be more appropriate to define multiple directory roots,
> where,
> in windows there would be one per drive, in unix one for the whole tree by
> default and virtual directory hierarchies just get a new directory root?

I am not sure exactly what you mean but you can add multiple path mappings.
I haven't added by default but you could setup some base paths which Squeak
could use internally so that URI doesn't change but the destination does.

> 
> so, it would require an explicit "open" of the zip, which returns that new
> directory root, so work on that is possible.
> 
> it probably would also allow for new file types to be supported without
> changing your parser more easily.

New types are easily added, I am working on tiding that bit up now.

Thanks for the feedback
Russell