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.

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.  It would be harder to read the resulting URL than the
original one, but then again all the other URL types end up doing this
anyway.  Be sure, if anyone codes this up, to make sure that all
existing FileURL's get updated.  This probably requires making it a
sequence of two changesets: one that absolutizes any existing relative
FileURL's, and the second which actually removes all the code to support
relative FileURL's.



Lex