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 [1] http://www.squeaksource.com/WebClient.html |
On 17 June 2010 06:07, Andreas Raab <[hidden email]> 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 > > [1] http://www.squeaksource.com/WebClient.html > > -- Best regards, Igor Stasenko AKA sig. |
I am fine with this as HTTPSocket is maintained as a facade to WebClient.
--Hannes On 6/17/10, Igor Stasenko <[hidden email]> wrote: > On 17 June 2010 06:07, Andreas Raab <[hidden email]> 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 >> >> [1] http://www.squeaksource.com/WebClient.html >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
In reply to this post by Andreas.Raab
Yes,
ok for me to replace *Socket with WebClient. Thanks Bye Enrico
On Thu, Jun 17, 2010 at 05:07, Andreas Raab <[hidden email]> wrote: Hi - -- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick |
In reply to this post by Igor Stasenko
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 <[hidden email]> 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 > > -- Best regards, Igor Stasenko AKA sig. |
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 <[hidden email]> 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 |
In reply to this post by Andreas.Raab
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.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. > 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.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. >> > 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 > > > |
In reply to this post by Andreas.Raab
Hi,
now that I try to update to trunk (from behind an authentication proxy) after a short while I get a debug window with
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
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 10282On Sat, Jul 10, 2010 at 23:20, Andreas Raab <[hidden email]> wrote:
-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick |
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 <[hidden email]> Hi, |
In reply to this post by espin
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 |
In reply to this post by espin
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 <[hidden email] > <mailto:[hidden email]>> 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 <[hidden email]> wrote:
-- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick |
In reply to this post by Andreas.Raab
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-
On Mon, Jul 12, 2010 at 10:27, Andreas Raab <[hidden email]> wrote:
-- 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 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.18 > > > On Mon, Jul 12, 2010 at 10:27, Andreas Raab <[hidden email] > <mailto:[hidden email]>> 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 <[hidden email]> wrote:
You mean Network-ar.74.mcz, don't you? (I was already on latest for WebClient)
-- 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 <[hidden email] > <mailto:[hidden email]>> 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 <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> 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 > > > > |
Free forum by Nabble | Edit this page |