[Q] Isn't 'file://foo/bar' asUrl supposed to give a relative FileUrl?

Bert Freudenberg bert at isg.cs.uni-magdeburg.de
Sun Aug 17 21:21:52 UTC 2003


Lex Spoon wrote:

> Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> wrote:
> 
> 
>>>It's a useful extension.  Such a URL is not covered in the RFC's, but it
>>>is useful and people do it.
>>
>>I don't think it's useful. I'd consider it even bad and confusing (like 
>>this discussion clearly shows) because the power of URLs stems from the 
>>simple fact that it is *only* a well-defined string. Also, the code 
>>becomes rather ugly, with "isAbsolute ifTrue: [...]" scattered around 
>>the place.
> 
> 
> It lets you point Scamper at "file:Blah.cs" that you just filed out. 
> Isn't this useful?  I did this all the time when running web browsers
> from a command line, though I grant I don't do it in Squeak very often.

I was actually referring to that particular implementation. The feature 
itself is useful, as I wrote in my last message.

> Also, is it really better to throw errors if a URL like this comes in? 
> If we really wanted to get into it, then there seems to be a place for
> two kinds of parsers: one that is strict and one that is loose and
> smart.  The current tradeoff is that if there is a strict parsing, then
> that is the one followed, and if there is not a strict parsing, then
> sometimes a smart parsing is used.  This seems very reasonable if there
> is to be only one parser for both kinds of applications.
> 
> The best resolution I can think of would be for the URL parser to
> convert it to a proper absolute file URL, instead of keeping it relative
> internally.  

That's more or less what I was suggesting. As soon as you create a URL 
from a String, apply all ad-hoc guestimates you want, but return a valid 
URL.

-- Bert



More information about the Squeak-dev mailing list