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
|