Zinc: urls without scheme

> Hi Igor,
>
> On 05 Aug 2011, at 10:08, Igor Stasenko wrote:
>
>> 'www.squeaksource.com' asZnUrl host -> nil
>
> That seems like a bug to me, I'll look into it. Thanks for reporting this.
>
>> 'http://www.squeaksource.com' asZnUrl host ->  'www.squeaksource.com'
>>
>> i wonder if url should have notion of default scheme and if sheme not
>> specified, use a default one i.e. 'http:' ?
>
> Hmm, that is more or less by design, I'll think about it.
>
> A default can also be explicit in the message like #portOrDefault that way the object keeps representing what was parsed, but the user specifies what kind of default behavior (s)he wants.
>

> On 5 August 2011 10:52, Sven Van Caekenberghe <[hidden email]> wrote:
>> Hi Igor,
>>
>> On 05 Aug 2011, at 10:08, Igor Stasenko wrote:
>>
>>> 'www.squeaksource.com' asZnUrl host -> nil
>>
>> That seems like a bug to me, I'll look into it. Thanks for reporting this.
>>
>>> 'http://www.squeaksource.com' asZnUrl host ->  'www.squeaksource.com'
>>>
>>> i wonder if url should have notion of default scheme and if sheme not
>>> specified, use a default one i.e. 'http:' ?
>>
>> Hmm, that is more or less by design, I'll think about it.
>>
>> A default can also be explicit in the message like #portOrDefault that way the object keeps representing what was parsed, but the user specifies what kind of default behavior (s)he wants.
>>
>
> Well, since zinc is mostly for http/web.. i would expect that it using
> appropriate defaults for urls it use.
>
> 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.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> Hi Igor,
>
> On 05 Aug 2011, at 10:08, Igor Stasenko wrote:
>
>> 'www.squeaksource.com' asZnUrl host -> nil
>
> That seems like a bug to me, I'll look into it. Thanks for reporting this.
>
>> 'http://www.squeaksource.com' asZnUrl host ->  'www.squeaksource.com'
>>
>> i wonder if url should have notion of default scheme and if sheme not
>> specified, use a default one i.e. 'http:' ?
>
> Hmm, that is more or less by design, I'll think about it.
>
> A default can also be explicit in the message like #portOrDefault that way the object keeps representing what was parsed, but the user specifies what kind of default behavior (s)he wants.

> 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
>
>
>
>

> 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 <[hidden email]> 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
>>
>>
>>
>>
>
>
>

>
> On 11 Aug 2011, at 14:52, Igor Stasenko wrote:
>
>> 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 ;)
>
> OK ;-)
>
>> 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.
>
> Well, I did some commits (with more tests) adding support so that
>
>        ZnUrl fromString: 'www.squeaksource.com/installer' defaultScheme: #http
>
> becomes equivalent to
>
>        ZnUrl fromString: 'http://www.squeaksource.com/installer'
>
> although I think the second is better (and it is what #asZnUrl currently wants).
>
> I did not (yet) change the current behavior of #asZnUrl to either always use #http as default scheme or throw an exception for a missing scheme, because I still think that it can be useful to have neither of these two behaviors, see for example ZnUrlTests>>#testParsePathOnly and ZnUrlTests>>#testRelative. But maybe we'll come across more arguments in the future.
>

> Sven
>
>> On 11 August 2011 14:24, Sven Van Caekenberghe <[hidden email]> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

> I don't understand how relative urls are ehmm related to this.
> By definition, you cannot construct a relative url out of a single
> argument, because it raising a question, relative to what?
> So, the right way to construct relative url is to be:
>
> relativeUrl := 'about.html' asRelativeUrlTo: someBaseUrl.
>
> while:
>
> relativeUrl := 'about.html' asRelativeUrl
>
> makes no sense at all.
>
> That means, in own turn, that expression
> 'xyz' asUrl
> could only be used for producing absolute urls with all consequence
> (such as picking default scheme etc).