Lex Spoon wrote:

> Markus Gaelli <gaelli at emergent.de> wrote:
> 
>>>>You mean a "relative url"? There is no such thing.
>>
>>Mmmh, but why is there an instance-variable called "isAbsolute" in 
>>FileUrl?
>>Should we get rid of that?
> 
> 
> 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.

If you really need to have a class representing "relative URLs" (instead 
of just using strings) why not make one? Call it NonAbsoluteUrlPart or 
something. I bet the code becomes way cleaner because all the 
conditionals go away, both in FileUrl and the new one.

> It also means that a url like 'www.abc.com'
> (also not in the RFC's) can be parsed as 'http://www.abc.com'.  

I disagree. It's not a URL. What you mean is a "smart" conversion of a 
user-entered bunch of characters into a meaningful URL. That's mostly a 
UI issue. But since in Squeak often the UI is just a Workspace, how 
about this: As soon as you create a URL from that String, the missing 
'http://' is prepended. In fact, this *is* exactly what happens now, and 
it's fine. We could make it a bit more useful by guessing from a 'www.' 
or 'ftp.' prefix, instead of always returning an HttpUrl.

> I didn't realize that a host was required for file url's.  It's almost useless,
> especially for Squeak, but I guess it would better nice to support the standard here.

Right. IMHO, until we feed URLs to the file primitives (which may have a 
way to make use of the host), we should raise an error if a file URL 
with a non-empty host part other than 'localhost' is converted to a path 
name.

-- Bert