Resources (was RE: File URI)

goran.krampe at bluefish.se goran.krampe at bluefish.se
Thu Apr 29 10:19:37 UTC 2004


Hi!

"Russell Penney" <russell.penney at tincanct.com> wrote:
> 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.

Sure! :) Sidetracking is cool. My partial rewrite of FileUrl was because
I wanted to fix a BUG in Scamper and, well - one thing led to another.

> 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.

That I think most of us agree with. And yes, SM uses a file for the
ImageSegment and files for the filecache - and yes, I did get bitten by
the 31-char limit of HFS in MacOS-pre-X, etc.. :)

[SNIP of stuff reminding me too of Flow]
> 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' ))

Btw, Flow will probably finally enter Squeak ("enter" as in "being a
core package people use") when the Squat stuff eventually meets up with
vanilla Squeak. That is at least my guess. :)


<flimsy-chain-of-thought>

Now, just to be nitpicky :) and also to show that I am not a URI expert:
Is the 'file:///dir1/dir2/file1.jpg' a valid URI? I assume it is. And
the path 'dir1/dir2/file1.jpg' is then an absolute path I assume (just
like I argue it is in FileUrl) which means that it wouldn't be portable.

Because most Win32 absolute paths begin with a drive letter volume etc
etc. Just thinking loud here.

What I would like to have (I think) is a way to refer to files:

1. Relative to the working directory. Righ now I do a lot of
"FileDirectory default" yaddayadda.
2. With an agreed upon cross platform set of rules.

This would at least facilitate using the local filesystem to store stuff
as files. :) AFAICT the need we have had at least in some cases
(BFAV/SM) is that the Squeak app needs to store state outside of the
image either for sharing between images or for simple robustness (the
image sometimes go boom).

Yes, of course a proper robust lightweight and base image standard OODB
would be what I *really want*. Magma is pretty close to that - though I
am not sure how intrusive it is in the image. GOODS is IMHO disqualified
because it is not pure Squeak and I don't think it qualifies as
lightweight either. Are there more contenders?

Ok, </flimsy-chain-of-thought>.

regards, Göran



More information about the Squeak-dev mailing list