Hi -
I'm interested in doing a little assault on the aforementioned classes. The only reason for the existence of Old[SimpleClient]Socket is that they're superclasses of HTTPSocket which is a beast to get rid of since we need it for updating etc.
However, with WebClient [1] at hand, we can convert HTTPSocket into a simple facade that just delegates everything to WebClient and in addition to having a better HTTP client implementation we could also get rid of these Old* classes.
What do people think? Is there any value in preserving the Old* classes and HTTPSocket or should we try to take an end-run on the issue? Obviously, there will be some tricky updating involved so I'd like to get opinions beforehand.
Cheers, - Andreas
On 17 June 2010 06:07, Andreas Raab andreas.raab@gmx.de wrote:
Hi -
I'm interested in doing a little assault on the aforementioned classes. The only reason for the existence of Old[SimpleClient]Socket is that they're superclasses of HTTPSocket which is a beast to get rid of since we need it for updating etc.
However, with WebClient [1] at hand, we can convert HTTPSocket into a simple facade that just delegates everything to WebClient and in addition to having a better HTTP client implementation we could also get rid of these Old* classes.
What do people think? Is there any value in preserving the Old* classes and HTTPSocket or should we try to take an end-run on the issue? Obviously, there will be some tricky updating involved so I'd like to get opinions beforehand.
Seems like a logical move, as to me. This however makes WebClient to be a core part of image, since many facilities, like MC using http to connect with outer world. I am not opposed to it, just have one question: how do you think it should be maintained? a) as an integral part of squeak-trunk b) as a separate package
Cheers, - Andreas
I am fine with this as HTTPSocket is maintained as a facade to WebClient.
--Hannes
On 6/17/10, Igor Stasenko siguctua@gmail.com wrote:
On 17 June 2010 06:07, Andreas Raab andreas.raab@gmx.de wrote:
Hi -
I'm interested in doing a little assault on the aforementioned classes. The only reason for the existence of Old[SimpleClient]Socket is that they're superclasses of HTTPSocket which is a beast to get rid of since we need it for updating etc.
However, with WebClient [1] at hand, we can convert HTTPSocket into a simple facade that just delegates everything to WebClient and in addition to having a better HTTP client implementation we could also get rid of these Old* classes.
What do people think? Is there any value in preserving the Old* classes and HTTPSocket or should we try to take an end-run on the issue? Obviously, there will be some tricky updating involved so I'd like to get opinions beforehand.
Seems like a logical move, as to me. This however makes WebClient to be a core part of image, since many facilities, like MC using http to connect with outer world. I am not opposed to it, just have one question: how do you think it should be maintained? a) as an integral part of squeak-trunk b) as a separate package
Cheers, - Andreas
-- Best regards, Igor Stasenko AKA sig.
On 6/16/2010 9:14 PM, Igor Stasenko wrote:
Seems like a logical move, as to me. This however makes WebClient to be a core part of image, since many facilities, like MC using http to connect with outer world. I am not opposed to it, just have one question: how do you think it should be maintained? a) as an integral part of squeak-trunk b) as a separate package
There's a difference between maintenance and development. The package should be "maintained" in trunk if included in trunk. That means that fixes that are required to keep it working are applied to it regardless of the upstream situation.
The package should be "developed" separately though. That means I'll be adding new features and merge other changes in its own repository. When a new version is good and ready it can be merged into the trunk as appropriate.
Makes sense?
Cheers, - Andreas
On 18 June 2010 05:40, Andreas Raab andreas.raab@gmx.de wrote:
On 6/16/2010 9:14 PM, Igor Stasenko wrote:
Seems like a logical move, as to me. This however makes WebClient to be a core part of image, since many facilities, like MC using http to connect with outer world. I am not opposed to it, just have one question: how do you think it should be maintained? a) as an integral part of squeak-trunk b) as a separate package
There's a difference between maintenance and development. The package should be "maintained" in trunk if included in trunk. That means that fixes that are required to keep it working are applied to it regardless of the upstream situation.
The package should be "developed" separately though. That means I'll be adding new features and merge other changes in its own repository. When a new version is good and ready it can be merged into the trunk as appropriate.
Makes sense?
Yes. It requires a bit more work, but in general, i want to see more and more packages living in own repositories, and be included into images using automated build.
Ok. Since HTTPSocket will depend on WebClient, then how you plan to deal with it? Put its implementation into separate package or merge with WebClient?
Cheers, - Andreas
On 6/18/2010 12:29 AM, Igor Stasenko wrote:
Ok. Since HTTPSocket will depend on WebClient, then how you plan to deal with it? Put its implementation into separate package or merge with WebClient?
Neither. I'm thinking of delegating from HTTPSocket to some other implementation using a class var in HTTPSocket so that one can register the HTTP client implementation with HTTPSocket when loading an implementation such as WebClient.
I'm also starting to wonder if one couldn't retain an *extremely* simple HTTPSocket implementation that doesn't deal with anything complicated (i.e., no proxy support, no redirect, no auth, just the simplest possible case) and have a more fully fledged client handle the more complicated uses. (the idea is mainly to keep MC working for the bootstrap cases where you can assume a simplified environment)
Cheers, - Andreas
On 6/18/10, Andreas Raab andreas.raab@gmx.de wrote: ....
I'm also starting to wonder if one couldn't retain an *extremely* simple HTTPSocket implementation that doesn't deal with anything complicated (i.e., no proxy support, no redirect, no auth, just the simplest possible case) and have a more fully fledged client handle the more complicated uses. (the idea is mainly to keep MC working for the bootstrap cases where you can assume a simplified environment)
I like this idea very much for different reasons - stability - robustness - documentation value - elegance
Hannes
On 6/18/2010 12:47 AM, Andreas Raab wrote:
I'm also starting to wonder if one couldn't retain an *extremely* simple HTTPSocket implementation that doesn't deal with anything complicated (i.e., no proxy support, no redirect, no auth, just the simplest possible case) and have a more fully fledged client handle the more complicated uses. (the idea is mainly to keep MC working for the bootstrap cases where you can assume a simplified environment)
All right, the deed is done :-) The commit message didn't show since it's been too big but you can find it here:
http://lists.squeakfoundation.org/pipermail/packages/2010-July/003526.html
In addition the latest version of WebClient now registers itself with HTTPSocket so that if you load WebClient it will provide the implementation for HTTPSocket requests.
Please note that there's potential for breakage since the rewrite was quite significant. If you notice anything that's broken please report the issues here.
Cheers, - Andreas
On 7/10/10 2:20 PM, Andreas Raab wrote:
On 6/18/2010 12:47 AM, Andreas Raab wrote:
I'm also starting to wonder if one couldn't retain an *extremely* simple HTTPSocket implementation that doesn't deal with anything complicated (i.e., no proxy support, no redirect, no auth, just the simplest possible case) and have a more fully fledged client handle the more complicated uses. (the idea is mainly to keep MC working for the bootstrap cases where you can assume a simplified environment)
All right, the deed is done :-) The commit message didn't show since it's been too big but you can find it here:
http://lists.squeakfoundation.org/pipermail/packages/2010-July/003526.htmlIn addition the latest version of WebClient now registers itself with HTTPSocket so that if you load WebClient it will provide the implementation for HTTPSocket requests.
Please note that there's potential for breakage since the rewrite was quite significant. If you notice anything that's broken please report the issues here.
Any possiblity for support for https?
Lawson
On Sun, 11 Jul 2010, Lawson English wrote:
On 7/10/10 2:20 PM, Andreas Raab wrote:
On 6/18/2010 12:47 AM, Andreas Raab wrote:
I'm also starting to wonder if one couldn't retain an *extremely* simple HTTPSocket implementation that doesn't deal with anything complicated (i.e., no proxy support, no redirect, no auth, just the simplest possible case) and have a more fully fledged client handle the more complicated uses. (the idea is mainly to keep MC working for the bootstrap cases where you can assume a simplified environment)
All right, the deed is done :-) The commit message didn't show since it's been too big but you can find it here:
http://lists.squeakfoundation.org/pipermail/packages/2010-July/003526.htmlIn addition the latest version of WebClient now registers itself with HTTPSocket so that if you load WebClient it will provide the implementation for HTTPSocket requests.
Please note that there's potential for breakage since the rewrite was quite significant. If you notice anything that's broken please report the issues here.
Any possiblity for support for https?
Load the Cryptography package then the SSL package from http://squeaksource.com/Cryptography.html. After that you'll have a class named HttpsSocket. For acceptable performance you'll probably need the DESPlugin for your platform.
Levente
Lawson
Hi, now that I try to update to trunk (from behind an authentication proxy) after a short while I get a debug window with
Error: Could not access http://spurce.squeak.org/trunk
The problem seems to originate in MCHttpRepository>>allFileNames where the call to HTTPSocket httpGet:args:user:passwd: does not succeed.
I retried my initialization for web
HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'.
but it now fails.
Do I have to download .mcz manually from squeak source? Any hints?
Thanks in advance Bye Enrico PS: I was/am at update 10282
On Sat, Jul 10, 2010 at 23:20, Andreas Raab andreas.raab@gmx.de wrote:
On 6/18/2010 12:47 AM, Andreas Raab wrote:
I'm also starting to wonder if one couldn't retain an *extremely* simple HTTPSocket implementation that doesn't deal with anything complicated (i.e., no proxy support, no redirect, no auth, just the simplest possible case) and have a more fully fledged client handle the more complicated uses. (the idea is mainly to keep MC working for the bootstrap cases where you can assume a simplified environment)
All right, the deed is done :-) The commit message didn't show since it's been too big but you can find it here:
http://lists.squeakfoundation.org/pipermail/packages/2010-July/003526.html
In addition the latest version of WebClient now registers itself with HTTPSocket so that if you load WebClient it will provide the implementation for HTTPSocket requests.
Please note that there's potential for breakage since the rewrite was quite significant. If you notice anything that's broken please report the issues here.
Cheers,
- Andreas
Enrico,
just updated a trunk image through a proxy here without any problems, but the proxy needs no authentication, so I can't say if this got broken on the way. I would try to do a full update via a direct connection and see if the problem with your proxy is still there with the fully updated image.
Alex
2010/7/12 Enrico Spinielli enrico.spinielli@googlemail.com
Hi, now that I try to update to trunk (from behind an authentication proxy) after a short while I get a debug window with
Error: Could not access http://spurce.squeak.org/trunk
The problem seems to originate in MCHttpRepository>>allFileNames where the call to HTTPSocket httpGet:args:user:passwd: does not succeed.
I retried my initialization for web
HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif '.
but it now fails.
Do I have to download .mcz manually from squeak source? Any hints?
Thanks in advance Bye Enrico PS: I was/am at update 10282
On Sat, Jul 10, 2010 at 23:20, Andreas Raab andreas.raab@gmx.de wrote:
On 6/18/2010 12:47 AM, Andreas Raab wrote:
I'm also starting to wonder if one couldn't retain an *extremely* simple HTTPSocket implementation that doesn't deal with anything complicated (i.e., no proxy support, no redirect, no auth, just the simplest possible case) and have a more fully fledged client handle the more complicated uses. (the idea is mainly to keep MC working for the bootstrap cases where you can assume a simplified environment)
All right, the deed is done :-) The commit message didn't show since it's been too big but you can find it here:
http://lists.squeakfoundation.org/pipermail/packages/2010-July/003526.html
In addition the latest version of WebClient now registers itself with HTTPSocket so that if you load WebClient it will provide the implementation for HTTPSocket requests.
Please note that there's potential for breakage since the rewrite was quite significant. If you notice anything that's broken please report the issues here.
Cheers,
- Andreas
-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick
On 7/12/2010 12:03 AM, Enrico Spinielli wrote:
I retried my initialization for web
HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'.but it now fails.
Do I have to download .mcz manually from squeak source? Any hints?
That's the expected behavior at this point - the support for authenticating proxies went out of the window in the simple default HTTPSocket implementation. You should be able to reinstate it by loading the latest version of WebClient from http://www.squeaksource.com/Webclient (you may need to have to download it through a webbrowser).
Please try it and let me know if that works.
Cheers, - Andreas
I uploaded latest WebClient [1] before issuing an update from Trunk but got stuck on MCConfiguration>>versionInfoNamed:for:from:
^(self versionNamed: newName for: dep from: repo) info
The return objs (the one paranthetized) is nil so asking for #info falis The version being scrutinazed (newName) was 'System-ar.349'
Hope it helps and thanks for the feedback. Bye Enrico PS: I am happy to test other suggestions but for the sake of having a working image I can bring one updated from a connection without the proxy...
[1] WebClient-
Core-ar.36 HTTP-ar.1 Help-ar.5 Tests-ar.18
On Mon, Jul 12, 2010 at 10:27, Andreas Raab andreas.raab@gmx.de wrote:
On 7/12/2010 12:03 AM, Enrico Spinielli wrote:
I retried my initialization for web
HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'.
but it now fails.
Do I have to download .mcz manually from squeak source? Any hints?
That's the expected behavior at this point - the support for authenticating proxies went out of the window in the simple default HTTPSocket implementation. You should be able to reinstate it by loading the latest version of WebClient from http://www.squeaksource.com/Webclient (you may need to have to download it through a webbrowser).
Please try it and let me know if that works.
Cheers,
- Andreas
On 7/12/2010 6:04 AM, Enrico Spinielli wrote:
I uploaded latest WebClient [1] before issuing an update from Trunk but got stuck on MCConfiguration>>versionInfoNamed:for:from:
^(self versionNamed: newName for: dep from: repo) info
The return objs (the one paranthetized) is nil so asking for #info falis The version being scrutinazed (newName) was 'System-ar.349'
Hope it helps and thanks for the feedback.
This looks like a Monticello issue (you probably need to flush the package cache for it to succeed). But the good news is that the missing proxy credentials were just an oversight on my part; I've posted a fix for it and with the fix you should be able to update again.
Cheers, - Andreas
Bye Enrico PS: I am happy to test other suggestions but for the sake of having a working image I can bring one updated from a connection without the proxy...
[1] WebClient-
Core-ar.36 HTTP-ar.1 Help-ar.5 Tests-ar.18On Mon, Jul 12, 2010 at 10:27, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
On 7/12/2010 12:03 AM, Enrico Spinielli wrote: I retried my initialization for web HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'. but it now fails. Do I have to download .mcz manually from squeak source? Any hints? That's the expected behavior at this point - the support for authenticating proxies went out of the window in the simple default HTTPSocket implementation. You should be able to reinstate it by loading the latest version of WebClient from http://www.squeaksource.com/Webclient (you may need to have to download it through a webbrowser). Please try it and let me know if that works. Cheers, - Andreas-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick
Hi all, I updated to latest WebClient as previously reported, flushed Monticello cache, updated to latest Trunk: failure as before...
Andreas, if you want I can continue to test further suggestions, otherwise it would be ok (and simpler for me) to just get off-line an updated image copy...
Please advise and thanks for the feedback Bye Enrico
On Tue, Jul 13, 2010 at 03:57, Andreas Raab andreas.raab@gmx.de wrote:
On 7/12/2010 6:04 AM, Enrico Spinielli wrote:
I uploaded latest WebClient [1] before issuing an update from Trunk but got stuck on MCConfiguration>>versionInfoNamed:for:from:
^(self versionNamed: newName for: dep from: repo) info
The return objs (the one paranthetized) is nil so asking for #info falis The version being scrutinazed (newName) was 'System-ar.349'
Hope it helps and thanks for the feedback.
This looks like a Monticello issue (you probably need to flush the package cache for it to succeed). But the good news is that the missing proxy credentials were just an oversight on my part; I've posted a fix for it and with the fix you should be able to update again.
You mean Network-ar.74.mcz, don't you? (I was already on latest for WebClient)
Bye
Enrico PS: I am happy to test other suggestions but for the sake of having a working image I can bring one updated from a connection without the proxy...
[1] WebClient-
Core-ar.36 HTTP-ar.1 Help-ar.5 Tests-ar.18
On Mon, Jul 12, 2010 at 10:27, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
On 7/12/2010 12:03 AM, Enrico Spinielli wrote:
I retried my initialization for web HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'. but it now fails. Do I have to download .mcz manually from squeak source? Any hints?That's the expected behavior at this point - the support for authenticating proxies went out of the window in the simple default HTTPSocket implementation. You should be able to reinstate it by loading the latest version of WebClient from http://www.squeaksource.com/Webclient (you may need to have to download it through a webbrowser).
Please try it and let me know if that works.
Cheers, - Andreas
-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick
On 7/13/2010 1:32 AM, Enrico Spinielli wrote:
if you want I can continue to test further suggestions, otherwise it would be ok (and simpler for me) to just get off-line an updated image copy...
I'm sorry if I haven't been clear, but yes, you *must* update your image offline to the latest version. Due to the nature of the update process you can't update 'through' the changes if you're using an authenticating proxy to update. So you'll have to update the image first, and once it's updated everything should work as before. If it doesn't, please send the SqueakDebug.log and any other information you can provide.
Cheers, - Andreas
Please advise and thanks for the feedback Bye Enrico
On Tue, Jul 13, 2010 at 03:57, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
On 7/12/2010 6:04 AM, Enrico Spinielli wrote: I uploaded latest WebClient [1] before issuing an update from Trunk but got stuck on MCConfiguration>>versionInfoNamed:for:from: ^(self versionNamed: newName for: dep from: repo) info The return objs (the one paranthetized) is nil so asking for #info falis The version being scrutinazed (newName) was 'System-ar.349' Hope it helps and thanks for the feedback. This looks like a Monticello issue (you probably need to flush the package cache for it to succeed). But the good news is that the missing proxy credentials were just an oversight on my part; I've posted a fix for it and with the fix you should be able to update again.You mean Network-ar.74.mcz, don't you? (I was already on latest for WebClient)
Bye Enrico PS: I am happy to test other suggestions but for the sake of having a working image I can bring one updated from a connection without the proxy... [1] WebClient- Core-ar.36 HTTP-ar.1 Help-ar.5 Tests-ar.18 On Mon, Jul 12, 2010 at 10:27, Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de> <mailto:andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>>> wrote: On 7/12/2010 12:03 AM, Enrico Spinielli wrote: I retried my initialization for web HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'. but it now fails. Do I have to download .mcz manually from squeak source? Any hints? That's the expected behavior at this point - the support for authenticating proxies went out of the window in the simple default HTTPSocket implementation. You should be able to reinstate it by loading the latest version of WebClient from http://www.squeaksource.com/Webclient (you may need to have to download it through a webbrowser). Please try it and let me know if that works. Cheers, - Andreas -- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick
Hi, just for feedback: I off-line (i.e. away from proxy) updated my image and then used it back behind the proxy and all is working fine.
Thanks for the help Bye enrico
On Tue, Jul 13, 2010 at 17:52, Andreas Raab andreas.raab@gmx.de wrote:
On 7/13/2010 1:32 AM, Enrico Spinielli wrote:
if you want I can continue to test further suggestions, otherwise it would be ok (and simpler for me) to just get off-line an updated image copy...
I'm sorry if I haven't been clear, but yes, you *must* update your image offline to the latest version. Due to the nature of the update process you can't update 'through' the changes if you're using an authenticating proxy to update. So you'll have to update the image first, and once it's updated everything should work as before. If it doesn't, please send the SqueakDebug.log and any other information you can provide.
Cheers,
- Andreas
Please advise and thanks for the feedback Bye Enrico
On Tue, Jul 13, 2010 at 03:57, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
On 7/12/2010 6:04 AM, Enrico Spinielli wrote:
I uploaded latest WebClient [1] before issuing an update from Trunk but got stuck on MCConfiguration>>versionInfoNamed:for:from: ^(self versionNamed: newName for: dep from: repo) info The return objs (the one paranthetized) is nil so asking for #info falis The version being scrutinazed (newName) was 'System-ar.349' Hope it helps and thanks for the feedback.This looks like a Monticello issue (you probably need to flush the package cache for it to succeed). But the good news is that the missing proxy credentials were just an oversight on my part; I've posted a fix for it and with the fix you should be able to update again.
You mean Network-ar.74.mcz, don't you? (I was already on latest for WebClient)
Bye Enrico PS: I am happy to test other suggestions but for the sake of having a working image I can bring one updated from a connection without the proxy... [1] WebClient- Core-ar.36 HTTP-ar.1 Help-ar.5 Tests-ar.18 On Mon, Jul 12, 2010 at 10:27, Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de> <mailto:andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>>> wrote: On 7/12/2010 12:03 AM, Enrico Spinielli wrote: I retried my initialization for web HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'. but it now fails. Do I have to download .mcz manually from squeak source? Any hints? That's the expected behavior at this point - the support for authenticating proxies went out of the window in the simple default HTTPSocket implementation. You should be able to reinstate itby loading the latest version of WebClient from http://www.squeaksource.com/Webclient (you may need to have to download it through a webbrowser).
Please try it and let me know if that works. Cheers, - Andreas -- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick
On 7/16/2010 12:35 AM, Enrico Spinielli wrote:
Hi, just for feedback: I off-line (i.e. away from proxy) updated my image and then used it back behind the proxy and all is working fine.
Great! Thanks for testing!
Cheers, - Andreas
Thanks for the help Bye enrico
On Tue, Jul 13, 2010 at 17:52, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
On 7/13/2010 1:32 AM, Enrico Spinielli wrote: if you want I can continue to test further suggestions, otherwise it would be ok (and simpler for me) to just get off-line an updated image copy... I'm sorry if I haven't been clear, but yes, you *must* update your image offline to the latest version. Due to the nature of the update process you can't update 'through' the changes if you're using an authenticating proxy to update. So you'll have to update the image first, and once it's updated everything should work as before. If it doesn't, please send the SqueakDebug.log and any other information you can provide. Cheers, - Andreas Please advise and thanks for the feedback Bye Enrico On Tue, Jul 13, 2010 at 03:57, Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de> <mailto:andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>>> wrote: On 7/12/2010 6:04 AM, Enrico Spinielli wrote: I uploaded latest WebClient [1] before issuing an update from Trunk but got stuck on MCConfiguration>>versionInfoNamed:for:from: ^(self versionNamed: newName for: dep from: repo) info The return objs (the one paranthetized) is nil so asking for #info falis The version being scrutinazed (newName) was 'System-ar.349' Hope it helps and thanks for the feedback. This looks like a Monticello issue (you probably need to flush the package cache for it to succeed). But the good news is that the missing proxy credentials were just an oversight on my part; I've posted a fix for it and with the fix you should be able to update again. You mean Network-ar.74.mcz, don't you? (I was already on latest for WebClient) Bye Enrico PS: I am happy to test other suggestions but for the sake of having a working image I can bring one updated from a connection without the proxy... [1] WebClient- Core-ar.36 HTTP-ar.1 Help-ar.5 Tests-ar.18 On Mon, Jul 12, 2010 at 10:27, Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de> <mailto:andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>> <mailto:andreas.raab@gmx.de <mailto:andreas.raab@gmx.de> <mailto:andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>>>> wrote: On 7/12/2010 12:03 AM, Enrico Spinielli wrote: I retried my initialization for web HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'. but it now fails. Do I have to download .mcz manually from squeak source? Any hints? That's the expected behavior at this point - the support for authenticating proxies went out of the window in the simple default HTTPSocket implementation. You should be able to reinstate it by loading the latest version of WebClient from http://www.squeaksource.com/Webclient (you may need to have to download it through a webbrowser). Please try it and let me know if that works. Cheers, - Andreas -- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick -- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick
On 2010/07/12 09:03, Enrico Spinielli wrote:
Hi, now that I try to update to trunk (from behind an authentication proxy) after a short while I get a debug window with
Error: Could not access http://spurce.squeak.org/trunk
^^^^^^ Did you type out the above by hand? Or, is "spurce" a typo in typing out the error message, or a typo in a preference?
frank
The problem seems to originate in MCHttpRepository>>allFileNames where the call to HTTPSocket httpGet:args:user:passwd: does not succeed.
I retried my initialization for web
HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'.but it now fails.
Do I have to download .mcz manually from squeak source? Any hints?
Thanks in advance Bye Enrico PS: I was/am at update 10282
On Sat, Jul 10, 2010 at 23:20, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
On 6/18/2010 12:47 AM, Andreas Raab wrote: I'm also starting to wonder if one couldn't retain an *extremely* simple HTTPSocket implementation that doesn't deal with anything complicated (i.e., no proxy support, no redirect, no auth, just the simplest possible case) and have a more fully fledged client handle the more complicated uses. (the idea is mainly to keep MC working for the bootstrap cases where you can assume a simplified environment) All right, the deed is done :-) The commit message didn't show since it's been too big but you can find it here: http://lists.squeakfoundation.org/pipermail/packages/2010-July/003526.html In addition the latest version of WebClient now registers itself with HTTPSocket so that if you load WebClient it will provide the implementation for HTTPSocket requests. Please note that there's potential for breakage since the rewrite was quite significant. If you notice anything that's broken please report the issues here. Cheers, - Andreas-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick
it is a by-hand typinng...
On Mon, Jul 12, 2010 at 11:18, Frank Shearar frank.shearar@angband.za.orgwrote:
On 2010/07/12 09:03, Enrico Spinielli wrote:
Hi, now that I try to update to trunk (from behind an authentication proxy) after a short while I get a debug window with
Error: Could not access http://spurce.squeak.org/trunk
^^^^^^Did you type out the above by hand? Or, is "spurce" a typo in typing out the error message, or a typo in a preference?
frank
The problem seems to originate in MCHttpRepository>>allFileNames where the call to HTTPSocket httpGet:args:user:passwd: does not succeed.
I retried my initialization for web
HTTPSocket useProxyServerNamed: 'xyz.zy.yz.zyx' port: xyzy proxyUser: 'xxx' password: 'yyyyyyy'. HTTPSocket httpShowGif: 'http://www.google.com/intl/en_ALL/images/logo.gif'.
but it now fails.
Do I have to download .mcz manually from squeak source? Any hints?
Thanks in advance Bye Enrico PS: I was/am at update 10282
On Sat, Jul 10, 2010 at 23:20, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
On 6/18/2010 12:47 AM, Andreas Raab wrote:
I'm also starting to wonder if one couldn't retain an *extremely* simple HTTPSocket implementation that doesn't deal with anything complicated (i.e., no proxy support, no redirect, no auth, just the simplest possible case) and have a more fully fledged client handle the more complicated uses. (the idea is mainly to keep MC working for the bootstrap cases where you can assume a simplified environment)All right, the deed is done :-) The commit message didn't show since it's been too big but you can find it here:
http://lists.squeakfoundation.org/pipermail/packages/2010-July/003526.html
In addition the latest version of WebClient now registers itself with HTTPSocket so that if you load WebClient it will provide the implementation for HTTPSocket requests.
Please note that there's potential for breakage since the rewrite was quite significant. If you notice anything that's broken please report the issues here.
Cheers, - Andreas
-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick
Yes, ok for me to replace *Socket with WebClient. Thanks Bye Enrico
On Thu, Jun 17, 2010 at 05:07, Andreas Raab andreas.raab@gmx.de wrote:
Hi -
I'm interested in doing a little assault on the aforementioned classes. The only reason for the existence of Old[SimpleClient]Socket is that they're superclasses of HTTPSocket which is a beast to get rid of since we need it for updating etc.
However, with WebClient [1] at hand, we can convert HTTPSocket into a simple facade that just delegates everything to WebClient and in addition to having a better HTTP client implementation we could also get rid of these Old* classes.
What do people think? Is there any value in preserving the Old* classes and HTTPSocket or should we try to take an end-run on the issue? Obviously, there will be some tricky updating involved so I'd like to get opinions beforehand.
Cheers,
- Andreas
squeak-dev@lists.squeakfoundation.org
-
Alexander Lazarević -
Andreas Raab -
Enrico Spinielli -
Frank Shearar -
Hannes Hirzel -
Igor Stasenko -
Lawson English -
Levente Uzonyi