[Q] Isn't 'file://foo/bar' asUrl supposed to give a relative
FileUrl?
Michael Rueger
michael at squeakland.org
Mon Aug 18 15:56:03 UTC 2003
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
More information about the Squeak-dev
mailing list
|