John, thank you

>>
>> John, could you please take a look at this humble creation for review  
>> and for a MacOS build? I think it has reached the point after which the  
>> main infrastructure will not change dramatically.
>
> ftpLocalWorkDir
>
> 	^FileDirectory on: 'c:\Danil\Deploy\Upload\tmp'
>

Ftp tests are very dependent on the local setup of the test evironment
(local running ftp server, etc). They never will work out of box. So
probably we can not get a lot of improvement in this area.

>
>>
>> I'm compiling recent versions of the plugin against a daily snapshot  
>> http://cool.haxx.se/curl-daily/, particulary this one: September 30,  
>> 2006 (because there are bugs being fixed). To get most of it libcurl  
>> should be compiled with c-ares (async DNS lookups) and OpenSSL.
>> Typical unix-like system will probably already have a stable libcurl  
>> installed, so here is a deployment complication - one needs to put  
>> newer libs (at least the version curl 7.15.5) somewhere in  
>> LD_LIBRARY_PATH before the libs present when starting Squeak.
>
> If you are going to run newer version of curl on os-x then we'll need to  
> statically link in the newer library.

Is it possible to have a statically linked shared library? That would be
an ideal solution, but as far as I know it is not possible with gnu tools,
yes (don't know how about MacOS)?

>>
>> As far a I know, the main difference between gnu-C and MacOS plugin  
>> versions will be in memory management functions they use (for example  
>> NewPtr instead of malloc). I've tried to abstract this difference into  
>> the CurlPlugin class>>macSpecificDefines using the idea found in the  
>> RePlugin.
>
> Nah, os-x is unix, calloc/malloc is fine, NewPtr is 1984 technology...

Heh, glad to hear that (not having MacOS at hand I had to rely on the
RePlugin comment :) )

> I'll note I think 11 tests ran, the only one that failed was to do with  
> that CURLINFO_FTP_ENTRY_PATH issue, and of course the ftp tests since  
> I'm too tire to alter ftpLocalWorkDir tonight.
>
> If you've only 11 tests, then I'd suggest others could add a few more  
> tests, that is the easy lifting of the project.

These tests are covering only an api implementation, that is they ensure
if the feature is implemented and can be used with good/bad input. Each of
the test covers an api-protocol family.
However, they doesn't check if behaviour is correct like what ftp test
does. Setting up proper test suit if what I think is the most daunting
task now

Cheers,
	Danil