I intend to subscribe to the php-and-curl list or whatever it's called :-) and MAY even be able to squeeze out some cycles to hack and/or document some stuff...
That said, I personally never had a problem searching the haxx.se site and finding out what CURLOPT_XYZ meant, except for the php-specific CURLOPT_BINARYTRANSFER... :-) I'd be hesitant to try and duplicate the libcurl docs onto the PHP site, as the whole point of PHP being a "glue" language and maintaining as much as possible of external lib idioms is to get documentation re-use out of the original docs, presumably maintained better by the original authors -- and they're pretty darn nice docs over on haxx.se, at least when I went looking for stuff. And anybody on the internals list can tell you I'm NOT the brightest bulb in the package. :-) On Tue, July 31, 2007 4:18 am, Steph Fox wrote: > Hi Daniel, all - > > Bit of history here: I promised Daniel last week I'd put some effort > into > the documentation side. That was before I started looking at the > extension... it has no tests and it needs a bit of love before it > should be > documented. I got as far as the simplest function having the wrong > signature > and realized this wasn't going to be a quickie. > > I don't have time to spend on ext/curl before disappearing on > vacation, > although I should have enough time after I get back if nobody else > gets to > it first. It's not complicated code, it just needs research. And > tests. And > then docs. > > - Steph > > > ----- Original Message ----- > From: "Daniel Stenberg" <[EMAIL PROTECTED]> > To: <internals@lists.php.net> > Sent: Tuesday, July 31, 2007 9:43 AM > Subject: [PHP-DEV] Regarding the ext/curl extension > > >> Hi PHP hackers! >> >> (I'm not subscribed, please CC me if you want me to read your >> responses.) >> >> I am the primary author and maintainer of the libcurl library, the >> underlying library that supports the PHP extension named... eh, >> right. >> What is the extension called really? CURL? ext/curl? curl? >> >> I'm writing to you to ask for your help to clear up some of the >> worst >> confusions you (in the PHP project) and we (in the cURL project) are >> causing the users of your PHP binding for libcurl. >> >> Here's the story (of course described here with my heavy bias): >> >> o You call the binding CURL or similar. The heavy mentioning of >> libcurl in >> your docs also tend to make PHP people to believe they actually >> "use >> libcurl". >> >> o There's a huge lack of docs for the PHP binding for libcurl on the >> php.net >> site. Most options are only listed with their names, so to figure >> out >> exactly what the names mean (and more) they need to search >> elsewhere. >> >> o The elsewhere is very much likely the curl web site, which indeed >> does >> have >> all the options documented (but for the libcurl C API, where they >> have >> the >> same names...). >> >> o But before the poor PHP users have reached the docs and figured >> out what >> they mean, they have run head-first into this wall: in our project >> we >> have a >> "libcurl" (which is a library with a C API/function interface) and >> we >> have a >> "curl" command line tool. >> >> So now the users are mighty confused. They think they're using >> CURL, >> curl or >> libcurl and here we claim they are not using curl nor libcurl... >> >> In a (private) conversation with a PHP team member he said the >> extension >> is >> called 'ext/curl' but I don't think that's a lot better since >> that's >> just >> going to be seen as "the extension called curl" to people. And >> then >> we're >> back on square 0. >> >> o In order to remedy this problem that really is a huge support >> issue for >> us >> (since for some funny reason the curl-and-php mailing list is >> hosted by >> us >> and I think I do the majority of the support on this list even >> though >> the >> binding is the product of your project...), I have simply decided >> to >> refer >> to the binding with a unique name that is not the exact same (case >> differences ignored) as one of our products. I call it PHP/CURL. >> (I did >> try >> to contact some of you back when this problem made my bubble >> burst, but >> I >> never got any responses and thus I proceeded anyway.) But now I'm >> here >> to >> let you know about my pains. >> >> o I've been told by more than one PHP team member that renaming the >> extension >> in your end is more or less out of the question, so even though I >> would >> *really* want that (and no other libcurl binding has hijacked one >> of our >> names like this), I can only see one really good way to solve this >> problem. >> And please do notice that this problem occurs only to YOUR users >> of YOUR >> binding. >> >> The Solution (as i see it - I'll just stress that again) >> >> You need to vastly extend the amount of documentation for the PHP >> binding >> for libcurl (I seriously don't know how to refer to it) on your site >> to >> drastically reduce the need for your users to go searching for the >> information on other sites, since the very moment they do that they >> enter >> the name- confusion maze and then a large amount of them are lost... >> >> This solution is rather half-baked, but I can't see any proper >> solution >> without a rename of the binding. >> >> Of course, it would also help if there would actually be PHP hackers >> involved on the curl-and-php mailing list to help out. >> >> I'll be happy to hear if you have any other thoughts or ideas on how >> to >> improve this situation. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
