cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [PHP-DEV] Streams: FTP/HTTP wrapper gurus wanted

From: Sterling Hughes <sterling_at_bumblebury.com>
Date: Sun, 11 Aug 2002 20:12:11 +0200

> Hi Sterling,
>
> I'm not sure :-)
> I'm 50/50 on integrating curl, because I know that it supports more features
> than the current wrappers, but I'm not sure if it supports a rich enough
> API to do the things that the streams API supports.
>
> So, I need your opinion:
>
> Does libcurl allow you to have progress notification callbacks,
> so that scripts/extensions can act on notifications such as mime type,
> file size, and overall progress?
> (I know it can print out a progress bar, but we need something a little
> bit more useful than that :-)
>

cURL can handle such things (progress notifications can go to a function).
I'm not sure why you would want MIME type notification, but we can add that
no problem, and maybe even cURL can be modified to make that easier...

cURL does support posting customized headers, btw, if that's where you
were going.

> Can we wrap a curl handle up into a stream without too much trouble?

Depends on how you define "too-much-trouble" :P

Using smart_str() and cURL's new multi interface.

there are some things that would be different, i would say optimized,
mainly that read () requests would be optimal case, not specified case,
ie, if the user specifies 1024 bytes to read, and 4096 are available
without blocking, then 4096 will be read (it goes without saying that we
can buffer this and return 1024).

An option could theortically be added to handle specified case instead
of optimized case. One of the great things about cURL is that the
author is very responsive.... I've forwarded him this message so that
(i forget if currently he's on vacation or not, which is the only time
I've ever head a reply lag) he can answer any questions that arise as
well...

> Is libcurl thread-safe?
>

yes, as long as you don't make it un-threadsafe :)

When using global dns caching, then it becomes un-ts, but if you avoid
this, than you should be fine. Daniel wrote up an API for mutexing
globals, and I've got this almost working (a bit more testing before I
post it), so this will also be an option (global DNS caching should
*greatly* improve speed for php apps, it is already somewhat done i
believe, but it can be handled better, and cURL does so).

You don't need to use the global dns cache, of course, and if you don't
everything else is threadsafe. cURL is heavily used in many
multi-thread applications (more so than php, i would gander).

> The other stuff should be relatively easy (like HEAD requests and so on),
> but if those two things look too hard, I'd be tempted to spend the effort
> on improving the streams code instead of trying to force libcurl to fit
> into streams.
>
> Last time I looked, I didn't like the look of libcurl, but it's been
> a while, so things might be better now.
>

Well, if we are talking about a permanent solution, I think cURL is a
much better choice, simply because:

1) its about 3 times as fast as the code in there now
2) its already gone to the trouble of messing with fucked up http, and
has plenty of debugging going into it (its becoming the replacement for
libwww btw).
3) it offers much richer support for http and ftp, as well as a miriad
of other protocols, I want my LDAP streams and I want them now!
4) Reuse, http and friends are constantly changing, we don't have the
resources properly, the cURL folks do. I would rather see one php
developer improving cURL to meet php's needs, than one php developer
maintaining such code in php (if that was even achievable).

-Sterling

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-08-11