On Wed, 5 Jan 2005, Richard Atterer wrote:

>> I'm about to improve this situation by converting the FTP code into a state
>> machine

> Very cool - many thanks! Do you also have plans to do the same for the CWD
> commands?

Yes. I plan to keep the FTP code written so that I can mix blocking and
non-blocking code, so that seldomly used code such as the krb4 one can be left
blocking (at least for now).

Then I hope to convert more and more of the command-response sections into
state-machine code. With the initial work, it should "just" be case of
converting more and more code. I don't have to do it all at once, it can be
done a little at a time. And for each command done, it improves libcurl a bit.

But before I proceed with that, I'll work on getting the current approach
integerated and taken advantage of properly with the multi interface.

> I'm not familiar enough with the curl code to say whether this looks "good".
> I hope that it won't end up as convoluted as libwww. I think what happened
> with libwww was that over time, "if-then-else" constructs were added to deal
> with certain server behaviour. However, such constructs result in additional
> states, and once a dozen or so is exceeded, it can get confusing...

Thanks for sharing your wisdom and experience on this topic.

I don't think the curl code will have to become that bad, even if it will turn
harder to read (than it is now) by this move. I'm also kind of hoping that
someone in the audience with stand up and complain if I don't do my job right,
and even that we will smoothen out potential initial problems by
collaborating.

With all the current test cases and future test cases we will write, I'm
pretty convinced we will have a pretty good ground to stand on even if the
code turns slightly harder to read.

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html