On Fri, 23 Aug 2002, Philip wrote:

[I've taken the liberty of Cc'ing this mail to the libcurl mailing list, I
thought that if I produce a really long and elaborate mail on this subect,
there might be more people out there that are interested in this.]

> My company is quite interested in using the multi feature of cURL from
> within PHP. I've been in touch with Sterling Hughes about this and he says
> it will be supported in PHP as soon as it goes non-beta in cURL.

Hm, okay. This sounds very interesting indeed! I've been in touch with Wez
Furlong on and off previously this summer because of his work with adding
some kind of use of the multi interface to PHP. I guess he has this
coordinated with Sterling.

I'm sorry but I'm not following the PHP devlopment that closely so I'm not
really into how PHP things turn until after a few months or so! ;-)

> Can you point me to the release plans / todo list? It would be a great
> help to know how much work there is left to do.

The multi interface already works. Most aspects of it. I still regard it
"early" as not that many people use it and thus it isn't extensively tested
and used and it hasn't been tested for a very long time yet.

We have several problems left for it to become really good:

o FOLLOWLOCATION doesn't work for this interface, which is mainly an
  oversight on my behalf but still needs to be fixed.

o It mainly works with HTTP(S) and FTP right now (which anyway is what 99.9%
  of all people care about). Getting the other protocols to work is mainly a
  matter of making sure they all work using the same select() core as the
  HTTP and FTP use.

o When it comes to writing to a URL, we have some features left to add: curl
  doesn't support chunked-transfer encoding on uploads, which makes it
  next to impossible to do uploads when you don't know the size of the upload
  before the action is taking place.

o When uploading data to a URL today, it is much too oriented to just
  uploading like an existing file or something. We need a way for the user/
  application to tell curl that "we have data to write now" and then it would
  call the read-callback as soon as the socket is writable. Today, it always
  call the read-callback when the socket is writable and there is no way for
  the callback to say "I have no data now but I expect to get some soon so
  I'm not done yet". Instead, if the callback returns 0 today curl treats
  that as an end-of-transfer and stops uploading.

o We don't do asynchronous name resolves yet, which thus can make multi
  interface calls block for quite a while when there's a name resolve
  involved. As mentioned before, this is being worked on in a separate
  project (http://libdenise.sourceforge.net).

o A few operations within libcurl still block when they shouldn't, when
  used with the multi interface.

o There is no test suite for it. It makes it hard to add some things as it
  can be really hard to verify that things actually work the way they are
  meant to.

Again, the multi interface mainly works and can indeed be deployed and used.
I need people to try it and use it as otherwise it won't get the testing it
needs and we won't get the bug reports we need in order to fix the problems
that I'm sure still lurks undiscovered in there!

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390