Lex Spoon wrote:

> Michael Rueger <michael at squeakland.org> wrote:


> But, I also think this kind of thing should be handled in the parser,
> not the protocol handler.  I don't even understand how the protocol
> handler *could* handle it.  If you have a parsed URL, then you have a
> scheme already and so it's too late to make a decision about what to do
> with 'www.google.com' or 'foo.txt'.  If there is going to be smart
> parsing, then it seems like the parser needs to do it.

That is exactly the point. The parser doesn't need to do anything with 
www.google.com. According to the RFC it is a perfectly valid *relative* 
URI. If you want e.g. Scamper to do something with it, then Scamper 
could complement the http://, as Scamper can relatively safely assume 
that you mean a http url.

>>none of the discussed problems are an issue.
>>E.g., 'g' asUrl -> http://g/  is one of these smart things that are just 
>>plain incorrect.

> What do you mean by incorrect?  This behavior is correct according to
> the letter of the RFC's, because the input is invalid to begin with. 

See above. The input is perfectly valid for a relative URI. This above 
behavior is one of the "smart" actions that actually get in the way. If 
I want to specify a relative URI that I at some later point want to 
resolve against a file, ftp, or http base address. the above doesn't let 
me do this. Is basically have to concatenate the Strings myself as

'g/' asUrl asUrlRelativeTo: 'file:/data/test' asUrl
yields

http://g/

as a result. It should be

'file:/data/test/g/'

> Finally, nothing in the URL hierarchy that has the 'ls' initials on it
> is a "hack".  I expected URL's to be a cornerstone of a WWW-friendly

Apologies, I didn't really mean hack in terms of quality of code. It is 
just that the things discussed above are not pure behavior and try to be 
too smart and have bitten me too many times. Please take a look at the 
URI package and then think of cases where you want to register new 
schemes and protocol handlers, a thing that the current url 
implementaiton just doesn't support because it makes assumptions about 
the meaning of the URI *strings*.

Michael