[Pharo-project] Zinc: urls without scheme
'www.squeaksource.com' asZnUrl host -> nil '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:' ? 'www.squeaksource.com' asUrl authority -> 'www.squeaksource.com' 'www.squeaksource.com' asUrl scheme -> 'http' -- 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. Regards, Sven
On 5 August 2011 10:52, Sven Van Caekenberghe <sven@beta9.be> 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.
Igor use gofer. It is good to minimise the number of libraries to maintain. Stef On Aug 5, 2011, at 11:07 AM, Igor Stasenko wrote:
On 5 August 2011 10:52, Sven Van Caekenberghe <sven@beta9.be> 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 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
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.
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 <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
On 11 August 2011 15:42, Sven Van Caekenberghe <sven@beta9.be> wrote:
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.
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).
Sven
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.
On 11 Aug 2011, at 17:01, Igor Stasenko wrote:
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).
That is not how I see it (for now at least). The difference between absolute and relative URLs is a known concept: http://en.wikipedia.org/wiki/Url#Absolute_vs_relative_URLs My view is that some string is parsed into an URL, which results in a object that has the (derived) property of being absolute or relative. It is true that a relative URL can only make sense in the context of a absolute URL, but that does not means that we cannot talk about or deal with a relative URL as a proper URL. Some intelligent operation to merge an absolute and relative one must be added in the future (this is possible only in a limited way now). In a sense, it comes down to what 'foo' as[Zn]Url should mean: either it is the host foo (old Url, browser interpretation), or the path foo (ZnUrl interpretation). Your point about the resulting error in your particular case is valid, I will look into that. But I still think that if you want a string to represent a URL unambiguously, you better add the scheme (as I wrote earlier). Sven
On Aug 5, 2011, at 10:52 AM, Sven Van Caekenberghe 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.
Yes it sound like a good idea.
Regards,
Sven
participants (3)
-
Igor Stasenko -
Stéphane Ducasse -
Sven Van Caekenberghe