[squeak-dev] Sockets, WebClient, HttpClient and friends

tim Rowledge tim at rowledge.org
Fri Jan 18 01:29:53 UTC 2019


Looking at the code I had a minor issue with the other day when loading from SqueakMap, I see what looks like a good opportunity to cleanup and simplify some classes. Since I'm most definitely not an expert in sockets and web interfaces etc I think some input from those of you more knowledgeable would be very helpful.

SqueakMap uses an HttpSocket directly to load; this has a problem in that the only error detection is to check the response for being a String. Which isn't the most robust or helpful technique. RBInternalSpellCheck does much the same, as do a few other users of #httpGet: (as an example).

InstallerInternetBased uses an http socket and checks the response for responding to #reset (I imagine as a proxy for stream-like behaviour?) which doesn't seem long-term robust.

Worst of all quite a few users of #httpGet: don't do any sort of checking and so will just dump users into a debugger; not our best look.

I know that WebClient is a somewhat heavier class but it does seem to do a lot more helpful things like handling redirects and so on as well as some better error testing. Would it be sensible to convert as much as practical to use WebClient instead of a plain HttpSocket? Might it be better to improve HttpSocket?

Some related stuff - there is an HttpClient class as well, unconnected to WebClient but used in several important looking places. Can that be improved or merged? At the very least it would be good to be able to document and comment code to explain why so many classes exist.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: TOAC: Turn Off Air Conditioner




More information about the Squeak-dev mailing list