Yes, of course we could just fix url and that's it. But my question was more general (because i knew why and where it fails ;) But ok.. If you think we should always explicitly use scheme, in that case, i think it should produce errors earlier, i.e. if it cannot detect any scheme, it should raise a malformed url error. Because as you can see in ScriptLoader new installingInstaller it throws error at random place, when MC trying to connect using URL. I'd prefer that URL throw an error, so we could see 1-2 stack frames below the caller who passing wrong url, but not like today, it buried under a lot of unrelated stuff from MC. On 11 August 2011 14:24, Sven Van Caekenberghe <sven@beta9.be> wrote:
Hi Igor,
On 05 Aug 2011, at 11:07, Igor Stasenko wrote:
The problem is in:
ScriptLoader new installingInstaller.
without default scheme this thing is broken, since it using url without scheme. :(
Of course i could use gofer for loading it.. but i found this is most easy way to load installer.
I studied this a bit, but the base problem is the specification of the MC location. If you replace:
mc := Smalltalk globals     at: #MCHttpRepository     fPresent: [ :repoClass | repoClass location: 'www.squeaksource.com/Installer' user: 'squeak' password: 'squeak' ].
with
mc := Smalltalk globals     at: #MCHttpRepository     ifPresent: [ :repoClass | repoClass location: 'http://www.squeaksource.com/Installer' user: 'squeak' password: 'squeak' ].
in ScriptLoader>>#installingInstaller,
it should work. Note that all MCHttpRepository are created like this, the template specifies it as well:
MCHttpRepository     location: 'http://www.squeaksource.com/'     user: ''     password: ''
I could make this into a patch/slice if you want.
Concering ZnUrl parsing, I am not sure that something has to change. ZnUrl is based on WAUrl that behaves the same. I just checked java.net.URL and they even throw an exception when you don't specify a scheme ;-) (because of the ambiguity).
Consider also relative URLs: for example, in the context of http://www.example.com:8080/examples/index.html, the relative URL about.html should be resolvable/composable to http://www.example.com:8080/examples/about.html. The current ZnUrl implementation sees about.html (but also foo.com) as a path, which is OK in this absolute/relative idea. The older Url class turns about.html into a host specification instead, which would be wrong from this prespective.
On the other hand, most browsers (and curl for example), will consider a string like 'foo' to mean a host as in http://foo
With the scheme prefix 'http://' you actually indicate what you want, maybe some extra API can support this default behavior programmatically, I am still thinking about this.
Regards,
Sven
-- Best regards, Igor Stasenko AKA sig.