Re: [PHP-DEV] Upgrade cURL extension
I'd sure like a PHP extension that didn't have this obvious and nasty bug: https://bugs.php.net/bug.php?id=46439 On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
Re: [PHP-DEV] Upgrade cURL extension
The oop interface to cURl is already available, take a look at http://pecl.php.net/package/pecl_http extension. It provides OOP interface and takes care of many of the input preparation or output parsing tasks normally you need to do in PHP when working with cURL. On Sat, Mar 10, 2012 at 12:49 PM, Simon Schick simonsimc...@googlemail.com wrote: 2012/3/10 Reindl Harald h.rei...@thelounge.net: Am 10.03.2012 18:28, schrieb Simon Schick: I'd like to see a new interface for curl in php ... I have no special idea how, but I heard from several people that they pretty much don't like the way curl is implemented in php. many other people would not like to break their perfect working code! Hi, Reindl I do not mean to drop the implementation as it is right now - but think of something different for the future. If there would be an additional implementation it would probably be like mysqli, where you have an oop-implmentation and a non-oop. Bye Simon -- 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
Re: [PHP-DEV] Upgrade cURL extension
Stas, That could work for people who don't have cURL built-in to their PHP version, but otherwise create a symbol conflict. On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- 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
Re: [PHP-DEV] Upgrade cURL extension
hi Tom, For one, it is mapped to the libcurl constants and behavior. Also this but report contains clear comment about this issue being a documentation problem, contribution welcome :) If you consider it as something that should be changed, then please feel free to add a comment there as well, or a patch :) But that's not really what we discuss here but the new code proposed by Pierrick. Cheers, On Sun, Mar 11, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: I'd sure like a PHP extension that didn't have this obvious and nasty bug: https://bugs.php.net/bug.php?id=46439 On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
I do see now that at curl did introduce the @ craziness. So it is unfair of me to single out PHP for introducing it. I'm not sure if the @ syntax is a sneaky feature of the standard C API, but it's definitely a sneaky feature of the command line utility. I did include a comment there when I first opened that bug report, proposing a more appropriate and sustainable interface. Documentation changes would make it possible to avoid the problem by looking carefully for strange gotchas in the fine print - but not to actually submit a value starting with a @, if, y'know, I wanted to do something crazy-nutty like send arbitrary data legal in any other form submission (: Apologies for hijacking the discussion. The '@' business does not come from libcurl. Native C libcurl On Sun, Mar 11, 2012 at 3:38 PM, Pierre Joye pierre@gmail.com wrote: hi Tom, For one, it is mapped to the libcurl constants and behavior. Also this but report contains clear comment about this issue being a documentation problem, contribution welcome :) If you consider it as something that should be changed, then please feel free to add a comment there as well, or a patch :) But that's not really what we discuss here but the new code proposed by Pierrick. Cheers, On Sun, Mar 11, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: I'd sure like a PHP extension that didn't have this obvious and nasty bug: https://bugs.php.net/bug.php?id=46439 On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
Re: [PHP-DEV] Upgrade cURL extension
Sigh, I could have edited that better, but I think the apology came across (: This is still a thing worth fixing. On Sun, Mar 11, 2012 at 6:09 PM, Tom Boutell t...@punkave.com wrote: I do see now that at curl did introduce the @ craziness. So it is unfair of me to single out PHP for introducing it. I'm not sure if the @ syntax is a sneaky feature of the standard C API, but it's definitely a sneaky feature of the command line utility. I did include a comment there when I first opened that bug report, proposing a more appropriate and sustainable interface. Documentation changes would make it possible to avoid the problem by looking carefully for strange gotchas in the fine print - but not to actually submit a value starting with a @, if, y'know, I wanted to do something crazy-nutty like send arbitrary data legal in any other form submission (: Apologies for hijacking the discussion. The '@' business does not come from libcurl. Native C libcurl On Sun, Mar 11, 2012 at 3:38 PM, Pierre Joye pierre@gmail.com wrote: hi Tom, For one, it is mapped to the libcurl constants and behavior. Also this but report contains clear comment about this issue being a documentation problem, contribution welcome :) If you consider it as something that should be changed, then please feel free to add a comment there as well, or a patch :) But that's not really what we discuss here but the new code proposed by Pierrick. Cheers, On Sun, Mar 11, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: I'd sure like a PHP extension that didn't have this obvious and nasty bug: https://bugs.php.net/bug.php?id=46439 On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
Re: [PHP-DEV] Upgrade cURL extension
I thought about it but I think it may confuse people to have two different extensions with the same name, same interface, but one in pecl and one in the core package (the difference between the 2 versions are not that big). Also as ilia mentioned if someone already have the original version, they will have symbol conflicts. So I guess we could just wait until PHP next unless someone have an other nice solution which will not confuse people :) Thanks all for your input. Pierrick On 11 March 2012 03:33, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
I think waiting until PHP++ is probably the best approach. It would've been nice to have the current libcurl version in 5.4.0, but since we're not talking about any critical bug/security fixes, I don't think it's that big a deal either way. So we may as well just sit on it for now. --Kris On Sun, Mar 11, 2012 at 8:55 PM, Pierrick Charron pierr...@webstart.frwrote: I thought about it but I think it may confuse people to have two different extensions with the same name, same interface, but one in pecl and one in the core package (the difference between the 2 versions are not that big). Also as ilia mentioned if someone already have the original version, they will have symbol conflicts. So I guess we could just wait until PHP next unless someone have an other nice solution which will not confuse people :) Thanks all for your input. Pierrick On 11 March 2012 03:33, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
hi Pierrick, I would rather go with php-next. The amount of changes are not safe for a now very stable version in 5.3 and 5.4 (same code base), while the code could be nicer as you did it in trunk. Cheers, On Sat, Mar 10, 2012 at 5:57 PM, Pierrick Charron pierr...@webstart.fr wrote: Hi all, As you may know, the cURL PHP extension is currently not in sync (featurewise) with the original libcurl. I started to work on it to make it as close as possible from the original libcurl. I also did some cleaning to make it easier to maintain (ordered all the constants/features by their libcurl version). All those changes were made on the trunk branch only. I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. So please, test the new version of the curl extension, review the code, and give your input on either or not those changes should be merge on 5.4.1 Thanks Pierrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
2012/3/10 Pierre Joye pierre@gmail.com hi Pierrick, I would rather go with php-next. The amount of changes are not safe for a now very stable version in 5.3 and 5.4 (same code base), while the code could be nicer as you did it in trunk. Cheers, On Sat, Mar 10, 2012 at 5:57 PM, Pierrick Charron pierr...@webstart.fr wrote: Hi all, As you may know, the cURL PHP extension is currently not in sync (featurewise) with the original libcurl. I started to work on it to make it as close as possible from the original libcurl. I also did some cleaning to make it easier to maintain (ordered all the constants/features by their libcurl version). All those changes were made on the trunk branch only. I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. So please, test the new version of the curl extension, review the code, and give your input on either or not those changes should be merge on 5.4.1 Thanks Pierrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, all I'd like to see a new interface for curl in php ... I have no special idea how, but I heard from several people that they pretty much don't like the way curl is implemented in php. May we have a little brainstorming around that .. may some other language has some good implementation ... When I see the list of constants, I feel like that is way to much ... this could be grouped somehow ... Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
Am 10.03.2012 18:28, schrieb Simon Schick: I'd like to see a new interface for curl in php ... I have no special idea how, but I heard from several people that they pretty much don't like the way curl is implemented in php. many other people would not like to break their perfect working code! signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Upgrade cURL extension
2012/3/10 Reindl Harald h.rei...@thelounge.net: Am 10.03.2012 18:28, schrieb Simon Schick: I'd like to see a new interface for curl in php ... I have no special idea how, but I heard from several people that they pretty much don't like the way curl is implemented in php. many other people would not like to break their perfect working code! Hi, Reindl I do not mean to drop the implementation as it is right now - but think of something different for the future. If there would be an additional implementation it would probably be like mysqli, where you have an oop-implmentation and a non-oop. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
I think all the php curl bindings should do is expose the power of curl in php with an interface similar to the c interface. I think it's up to third party libraries to put an easier to use interface on top of the curl bindings. Thanks, Michael On Mar 10, 2012, at 11:41 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 10.03.2012 18:28, schrieb Simon Schick: I'd like to see a new interface for curl in php ... I have no special idea how, but I heard from several people that they pretty much don't like the way curl is implemented in php. many other people would not like to break their perfect working code! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
