Am 14.05.2004 um 13:08 schrieb goran.krampe at bluefish.se:

> Colin Curtin <alpine at umail.ucsb.edu> wrote:
>> Hello to you all,
>>
>> I have built an almost* unconditionally HTTP/1.1 compliant client for 
>> Squeak
>> 3.6. It is very similar in style to Apache Jakarta's HTTPClient.
>
> Just wanted to say - great! :)

The intention is great indeed. Unfortunately, the actual implementation 
does not quite live up to its promises. (Skip to the bottom [*] if you 
just want a summary).

Sorry to have to say this, but I just needed an HTTP client to upload a 
file and thought I give this one a shot.

There is the invitingly-looking HCFacade>>httpPut:to:user:password: 
method, which is supposed to be as simple to use as the existing HTTP 
client interface. Unfortunately, all I get is a walkback. It's trying 
to use a URL method on a string. Oh, I have to give the url as String. 
Okay, no problem, my fault, it's just that HTTPSocket used Strings.

Well, another walkback. In #acceptUrl:. Ah, the HCBasicAuth token lacks 
an url. Hmm, how can this be? I gave it a decent URL to work with. 
Okay, pulling out my wizard scope, I see it was sent from 
#authenticatePreempt:. Hmm, I'll try to fix this, I just set the URL I 
gave to my initial call. Okay, simple enough, seems to work. Although I 
encountered quite strange-looking methods on my way to discover the 
cause of this failure.

No, not yet. Why is the PutMethod's outstream nil? I'm sure my stream 
was not nil when I passed it to the Facade. Oh, it's just ignored? 
Okay, another simple fix, after I waded through some more suspiciously 
ineffective code.

Hey, it worked now without a walkback, and without an error report. But 
... where's my uploaded file? Not where I intended to put it, at least. 
The URL I gave looked something like 
"http://domain.host/path/to/test.txt", but accessing this via a browser 
did not work. Consulting the server logs, I finally found the file, 
which was indeed uploaded successfully. However, it ended up in the 
directory "/path" and was named "totest.txt".

At this point I decided to not further investigate this package. I'm 
sorry if the above sounded a bit harsh, but your advertisement induced 
quite some expectations. Judging from your email address I hope you're 
open for some advice, so I want to share a few of my findings:

- There are way more efficient ways to select the maximum of a 
collection than to sort completely and return the last element (see 
#selectForUrl:).

- Your code repeatedly switches between string concatenation and 
streaming, in many cases the streams are only used to create strings 
which are put on streams whose contents is concatenated only to be put 
on yet another stream (see all the header generation). The result is 
both inelegant and inefficient. While achieving both, elegance and 
efficiency, is really hard, you should strive for at least one of them.

- Please try not to outsmart your fellow programmers. Do things step by 
step. Simple is Better. For example, if this method indeed does what it 
is supposed to do, I'm really afraid of digging any deeper for fear of 
getting knots in my brain:
    getPendingAuthsFor: aUrl
	^ self pending keys collect: [:url |
		aUrl = url ifTrue: [ self pending removeKey: url ]
	].
My guess is that the conditional in there never evaluates to false?

[*] (start reading here again if you skipped the above)

> Eventually we will probably need to dwell a bit on what to have as the
> "default base" package for this, AFAIK we now have three different HTTP
> client implementations, right?

While the overall design is sound, I do not think this particular 
implementation is a candidate for inclusion in the base image.

- Bert -

PS: A useful addition to SqueakMap would be a user-supplied rating.