Re: [PHP-DEV] Let's fork GD!
Well, I don't actually see a license problem for non-LZW compressed gifs. But I am still not sure supporting GIF is a productive thing to do. The format needs to die. No sense helping it stay alive. In the ideal world that would be true, but 90% of the web graphics files I get from the designers and advertising agencies are still in the gif format. There are still parts of the world where patent issues don't have an affect anyway. As long as there is possibility to patch the php version of gd I'm happy (http://www.rhyme.com.au/gd/). Anyway I think forking gd is an excellent idea. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
Well, as far as I understand it, simply reading an LZW compressed GIF would not violate the license. It is software that creates LZW-compressed GIF files that need to pay up. So, we could still support GIF and manipulate LZW-compressed files, but once we read it in and manipulate it, we would not be able to write out an LZW-compressed GIF. That means the GIF files created by PHP-GD would be much larger. -Rasmus On Fri, 12 Apr 2002, Edin Kadribasic wrote: Well, I don't actually see a license problem for non-LZW compressed gifs. But I am still not sure supporting GIF is a productive thing to do. The format needs to die. No sense helping it stay alive. In the ideal world that would be true, but 90% of the web graphics files I get from the designers and advertising agencies are still in the gif format. There are still parts of the world where patent issues don't have an affect anyway. As long as there is possibility to patch the php version of gd I'm happy (http://www.rhyme.com.au/gd/). Anyway I think forking gd is an excellent idea. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
On Friday, 12. April 2002 06:53, Rasmus Lerdorf wrote: Well, I don't actually see a license problem for non-LZW compressed gifs. But I am still not sure supporting GIF is a productive thing to do. The format needs to die. No sense helping it stay alive. +1 I think its not a good idea to support gif-format. We have a lot of alternative formats. We could compromise and support reading of GIF files. That way you can still use GIF image files from places, but you would write them back out as pngs. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
At 23:05 11/04/2002 -0700, Rasmus Lerdorf wrote: On Friday, 12. April 2002 06:53, Rasmus Lerdorf wrote: Well, I don't actually see a license problem for non-LZW compressed gifs. But I am still not sure supporting GIF is a productive thing to do. The format needs to die. No sense helping it stay alive. +1 I think its not a good idea to support gif-format. We have a lot of alternative formats. We could compromise and support reading of GIF files. That way you can still use GIF image files from places, but you would write them back out as pngs. Good idea. BTW are you sure that the patent is only on the LZW? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Let's fork GD!
Was composing that same message when I received it. +1 -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 1:05 AM To: Georg Richter Cc: Markus Fischer; Stig S. Bakken; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Let's fork GD! On Friday, 12. April 2002 06:53, Rasmus Lerdorf wrote: Well, I don't actually see a license problem for non-LZW compressed gifs. But I am still not sure supporting GIF is a productive thing to do. The format needs to die. No sense helping it stay alive. +1 I think its not a good idea to support gif-format. We have a lot of alternative formats. We could compromise and support reading of GIF files. That way you can still use GIF image files from places, but you would write them back out as pngs. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] HTTP/GET parameters not registered in $_GET
Win32, Apache 2.0.36-dev, PHP 4.3.0-dev. The script pre ?php print_r($_GET); ? outputs Array( ) when called with http://localhost/test.php?foo=bar using the CGI SAPI. When I switch to the Apache2Filter SAPI it outputs Array ( [foo] = bar ) which is, of course, correct. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
At 23:05 11/04/2002 -0700, Rasmus Lerdorf wrote: On Friday, 12. April 2002 06:53, Rasmus Lerdorf wrote: Well, I don't actually see a license problem for non-LZW compressed gifs. But I am still not sure supporting GIF is a productive thing to do. The format needs to die. No sense helping it stay alive. +1 I think its not a good idea to support gif-format. We have a lot of alternative formats. We could compromise and support reading of GIF files. That way you can still use GIF image files from places, but you would write them back out as pngs. Good idea. BTW are you sure that the patent is only on the LZW? The Unisys patent is definitely only on what are called LZ-78 type compression algorithms of which LZW is one. Actually, IBM has a similar patent, but only Unisys has made noises about enforcing it. See: http://www.gnu.org/philosophy/gif.html For a good explanation of the current status. They verify there that reading of LZW-GIF files is perfectly ok. It is only creating them that is an issue. The patent does expire in 2003 though. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Let's fork GD!
For a good explanation of the current status. They verify there that reading of LZW-GIF files is perfectly ok. It is only creating them that is an issue. The patent does expire in 2003 though. -Rasmus Well 2003 isn't all that far off. That will be a serious problem for PNG when the time comes (probably this have been the problem all along ... a lot of big players just waiting for the patent to expire) Well lets hope the same does not happen with JPEG2000 and their royalty free license. Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Reuchlinstr. 10-11 Gebäude 4 1.OG Raum 6 (4.1.6) 10553 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTTP/GET parameters not registered in $_GET
Sebastian Bergmann wrote: When I switch to the Apache2Filter SAPI it outputs Array ( [foo] = bar ) which is, of course, correct. I'm puzzled, because now - out of a sudden - it doesn't work with the Apache2Filter SAPI either. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Let's fork GD!
I don't see how it would be a problem for PNG. Who wants to go back to images limited to 8-bit colour and no alpha channel? GIF is an outdated format, I don't see it making a comeback in its current form. -Rasmus On Fri, 12 Apr 2002, Lukas Smith wrote: For a good explanation of the current status. They verify there that reading of LZW-GIF files is perfectly ok. It is only creating them that is an issue. The patent does expire in 2003 though. -Rasmus Well 2003 isn't all that far off. That will be a serious problem for PNG when the time comes (probably this have been the problem all along ... a lot of big players just waiting for the patent to expire) Well lets hope the same does not happen with JPEG2000 and their royalty free license. Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Reuchlinstr. 10-11 Gebäude 4 1.OG Raum 6 (4.1.6) 10553 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTTP/GET parameters not registered in $_GET
Sebastian Bergmann wrote: Sebastian Bergmann wrote: When I switch to the Apache2Filter SAPI it outputs Array ( [foo] = bar ) which is, of course, correct. I'm puzzled, because now - out of a sudden - it doesn't work with the Apache2Filter SAPI either. Update: It seems to work with a Debug_TS build of PHP, and does not work with a Release_TS build. Which doesn't make any sense... -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTTP/GET parameters not registered in $_GET
Sebastian Bergmann wrote: Update: It seems to work with a Debug_TS build of PHP, and does not work with a Release_TS build. Which doesn't make any sense... Just tested the PHP_4_2_0 branch, and it works fine. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTTP/GET parameters not registered in $_GET
Sebastian Bergmann wrote: Sebastian Bergmann wrote: Update: It seems to work with a Debug_TS build of PHP, and does not work with a Release_TS build. Which doesn't make any sense... Just tested the PHP_4_2_0 branch, and it works fine. I really don't know what this is / was about, but a release build of HEAD works now, too. So, everything seems to be fine... Strange things do happen, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Obsolete code in sapi_apache2.c
Since we no longer ask to add these lines
Files *.php
SetOutputFilter PHP
SetInputFilter PHP
/Files
to the httpd.conf in the apache2filter README, isn't it save to
remove the following lines from sapi_apache2.c?
/* for those who still have Set*Filter PHP configured */
while (f) {
if (strcmp(f-frec-name, PHP) == 0) {
ap_log_error(APLOG_MARK, APLOG_WARNING | APLOG_NOERRNO,
0, r-server,
\Set%sFilter PHP\ already configured for %s,
output ? Output : Input, r-uri);
return;
}
f = f-next;
}
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
+1 ! Agreed with GIF format, look at facelink.com, i'm sure 80% of the pictures uploaded there are from programs and cameras that default to GIF. I'm not really savy with graphics but isn't GIF the only format that allows for animated pictures? F. - Original Message - From: Edin Kadribasic [EMAIL PROTECTED] To: Rasmus Lerdorf [EMAIL PROTECTED]; Markus Fischer [EMAIL PROTECTED] Cc: Stig S. Bakken [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, April 12, 2002 2:49 AM Subject: Re: [PHP-DEV] Let's fork GD! Well, I don't actually see a license problem for non-LZW compressed gifs. But I am still not sure supporting GIF is a productive thing to do. The format needs to die. No sense helping it stay alive. In the ideal world that would be true, but 90% of the web graphics files I get from the designers and advertising agencies are still in the gif format. There are still parts of the world where patent issues don't have an affect anyway. As long as there is possibility to patch the php version of gd I'm happy (http://www.rhyme.com.au/gd/). Anyway I think forking gd is an excellent idea. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Let's fork GD!
Title: RE: [PHP-DEV] Let's fork GD! Rasmus Lerdorf writes: Well, I don't actually see a license problem for non-LZW compressed gifs. But I am still not sure supporting GIF is a productive thing to do. The format needs to die. No sense helping it stay alive. If there will be no gif support in the bundled gd, then there has to be a mechanism for using external gd libs, much like the mysql mechanism. The option --with-gd uses the bundled libs, --with-gd=/path/to/gd uses external libs. Removing support for gif images completely would be brutal, and isn't a decision that PHP should be making on behalf of its users. IMHO that is. Frankly, I think gif support should be included and disabled by default. Let the users decide. For the most part, they are a fairly smart bunch. Otherwise they'd be using asp or cf or some damn thing. :) Best Regards Mike Robinson To find out more about what we can do for you, please visit us at: http://www.tmgtv.ca/ and http://www.thestar.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
f Agreed with GIF format, look at facelink.com, i'm sure 80% of the f pictures uploaded there are from programs and cameras that default f to GIF. I'm not really savy with graphics but isn't GIF the only f format that allows for animated pictures? If you mean digital cameras, they usually default to JPEG/MPEG. As for animated pictures - does GD support that anyway? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 /ext/domxml php_domxml.c php_domxml.h
In cvssteinm1018611144@cvsserver, Uwe Steinmann wrote: steinmFri Apr 12 07:32:24 2002 EDT Modified files: /php4/ext/domxml php_domxml.c php_domxml.h Log: - append_child(): actually do an append child and not and add sibling mmh, you just broke some of my applications :) I know, it was the wrong behaviour before, but now I will have big troubles to make my application cross-version compatible (and it looks like, there's no method append_sibling with that old behaviour.) solutions? don't know. maybe adding a function with that old behaviour maybe, so i can check for this in my applications. maybe reverting (but then we don't follow w3c, but this function was in domxml for a long time..) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
It only reads the first frame, so it's not really supported, but the point was that there are a lot of GIF images around there (unfortunately), either static or animated. I also hope it dies like BMP, or even the stupid AOL ART format! Fab. - Original Message - From: Stanislav Malyshev [EMAIL PROTECTED] To: fabwash [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, April 12, 2002 8:57 AM Subject: Re: [PHP-DEV] Let's fork GD! f Agreed with GIF format, look at facelink.com, i'm sure 80% of the f pictures uploaded there are from programs and cameras that default f to GIF. I'm not really savy with graphics but isn't GIF the only f format that allows for animated pictures? If you mean digital cameras, they usually default to JPEG/MPEG. As for animated pictures - does GD support that anyway? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Proposal for aggregation vs. MI
On Fri, 12 Apr 2002, Andi Gutmans wrote: Hi, I think that if we go my way with aggregation we can add the ability to add aggregated classes at run-time too and answer your needs. Fine with me. However, I think that if we continue on much longer with trying to put all possible OOP features into Engine 2 it will never become a reality. I would like to make the aggregation patch the last thing in Engine 2 and then start working on testing it and working towards PHP 5. Otherwise we will never have a next version of PHP. There have been so many changes and lots of good changes we just can't do too much at once. We should do a feature freeze right after aggregation or we will be left with lots of discussions and ideas but no next version... It needs lots and lots of testing so that we can iron out all of the bugs. There can always be PHP 6 later on. I think feature wise the Engine 2 is a big step forward for PHP and we should try and get it out! What about the thing that I've been asking for a long time now, a better and more consistent way to specify function/method callbacks? -Andrei Linux is like living in a teepee. No Windows, no Gates, Apache in house. - Usenet signature -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
f It only reads the first frame, so it's not really supported, but f the point was that there are a lot of GIF images around there f (unfortunately), either static or animated. I also hope it dies f like BMP, or even the stupid AOL ART format! Well, I think animated GIFs will be a relic very soon, I guess, as soon as Flash support gains more coverage (most of browser do support it), and there's also MNG format which supports animation, though I don't really know its support status. MNG pages says mozilla and konq support it. No info about MSIE. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segfault in php_stream_url_wrap_http
When executing the stockquotes.php sample that comes with PEAR/SOAP my PHP (4.3.0-dev, CGI, Win32) segfaults: php_stream_url_wrap_http(_php_stream_wrapper * 0x00b93918, char * 0x00e69a30, char * 0x10258ba8 `string', int 12, char * * 0x, _php_stream_context * 0x, int 2, char * 0x1025aa10 `string', unsigned int 1107, char * 0x10263b58 `string', unsigned int 463, void * * * 0x00b32990) line 334 + 3 bytes php_stream_open_url(char * 0x00e69a30, char * 0x10258ba8 `string', int 12, char * * 0x, _php_stream_context * 0x, int 1, char * 0x1025aa10 `string', unsigned int 1143, char * 0x10263b58 `string', unsigned int 463, void * * * 0x00b32990) line 1107 + 108 bytes _php_stream_open_wrapper_ex(char * 0x00e69a30, char * 0x10258ba8 `string', int 12, char * * 0x, _php_stream_context * 0x, int 0, char * 0x10263b58 `string', unsigned int 463, char * 0x, unsigned int 0, void * * * 0x00b32990) line 1143 + 100 bytes zif_file(int 1, _zval_struct * 0x00e65690, _zval_struct * 0x, int 1, void * * * 0x00b32990) line 463 + 60 bytes execute(_zend_op_array * 0x00e68da0, void * * * 0x00b32990) line 1598 + 47 bytes execute(_zend_op_array * 0x00e5db68, void * * * 0x00b32990) line 1638 + 34 bytes execute(_zend_op_array * 0x00e5d148, void * * * 0x00b32990) line 1638 + 34 bytes execute(_zend_op_array * 0x00e169e8, void * * * 0x00b32990) line 1638 + 34 bytes execute(_zend_op_array * 0x00e146c0, void * * * 0x00b32990) line 1638 + 34 bytes execute(_zend_op_array * 0x00b4ac50, void * * * 0x00b32990) line 1638 + 34 bytes call_user_function_ex(_hashtable * 0x00bce2c0, _zval_struct * * 0x0012f948, _zval_struct * 0x0012f938, _zval_struct * * 0x0012f954, int 2, _zval_struct * * * 0x00b4a8c8, int 0, _hashtable * 0x, void * * * 0x00b32990) line 520 + 34 bytes overload_call_method(int 2, _zval_struct * 0x00e64fe0, _zval_struct * 0x00b5bf20, int 1, void * * * 0x00b32990, _zend_property_reference * 0x00b49b58) line 596 + 35 bytes call_overloaded_function(_temp_variable * 0x00b49b48, int 2, _zval_struct * 0x00e64fe0, void * * * 0x00b32990) line 953 + 36 bytes execute(_zend_op_array * 0x00b49928, void * * * 0x00b32990) line 1660 + 48 bytes zend_execute_scripts(int 8, void * * * 0x00b32990, _zval_struct * * 0x, int 3) line 810 + 34 bytes php_execute_script(_zend_file_handle * 0x0012ff48, void * * * 0x00b32990) line 1405 + 27 bytes main(int 1, char * * 0x00b32580) line 1020 + 17 bytes mainCRTStartup() line 338 + 17 bytes -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Let's fork GD!
IE support on PNG is far more mature on the Mac platform than it is on Windows/Solaris. Don't know when MS is planning to finish their implementation for these platforms but Alpha channels don't even work right yet so I think MNG support is at least another major release away. :( As far as GIFs go in my experience: 1. Animations don't need to be manipulated on the fly, so fpassthru() works just dandy 2. The designers/advertisers that supply GIFS are unlikely to be happy about a page that alters their work.fpassthru() again. 3. we should not make assumptions about the needs/desires of the ultimate user and should leave as many capabilities in PHP as makes sense. Having said that, I think we should leave GIF read capability by default. Write should not be enabled (at least until 2003). -- 100 monkeys given typewriters and 45 minutes could produce the entire source code for Windows. -- The same monkeys, given 5 minutes more would produce Earth in the Balance -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 8:17 AM To: fabwash Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Let's fork GD! f It only reads the first frame, so it's not really supported, but the f point was that there are a lot of GIF images around there f (unfortunately), either static or animated. I also hope it dies like f BMP, or even the stupid AOL ART format! Well, I think animated GIFs will be a relic very soon, I guess, as soon as Flash support gains more coverage (most of browser do support it), and there's also MNG format which supports animation, though I don't really know its support status. MNG pages says mozilla and konq support it. No info about MSIE. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Number of active sessions
Get to get a feel for common experience, what are the average and maximum number of active sessions on your web sites? It may be useful for sizing default values. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Obsolete code in sapi_apache2.c
On Fri, Apr 12, 2002 at 02:04:00PM +0200, Sebastian Bergmann wrote:
Since we no longer ask to add these lines
Files *.php
SetOutputFilter PHP
SetInputFilter PHP
/Files
to the httpd.conf in the apache2filter README, isn't it save to
remove the following lines from sapi_apache2.c?
/* for those who still have Set*Filter PHP configured */
while (f) {
if (strcmp(f-frec-name, PHP) == 0) {
ap_log_error(APLOG_MARK, APLOG_WARNING | APLOG_NOERRNO,
0, r-server,
\Set%sFilter PHP\ already configured for %s,
output ? Output : Input, r-uri);
return;
}
f = f-next;
}
Naw, we don't want to add the PHP filter twice.
-aaron
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Let's fork GD!
Well, supporting writing regular GIF files is not something we can legally do. It is not us making the decision. There will definitely be no writing of LZW-GIF files in PHP. I am not willing to blatantly violate a patent that is being actively enforced. -Rasmus On Fri, 12 Apr 2002, Robinson, Mike wrote: Rasmus Lerdorf writes: Well, I don't actually see a license problem for non-LZW compressed gifs. But I am still not sure supporting GIF is a productive thing to do. The format needs to die. No sense helping it stay alive. If there will be no gif support in the bundled gd, then there has to be a mechanism for using external gd libs, much like the mysql mechanism. The option --with-gd uses the bundled libs, --with-gd=/path/to/gd uses external libs. Removing support for gif images completely would be brutal, and isn't a decision that PHP should be making on behalf of its users. IMHO that is. Frankly, I think gif support should be included and disabled by default. Let the users decide. For the most part, they are a fairly smart bunch. Otherwise they'd be using asp or cf or some damn thing. :) Best Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
I don't think I have ever seen a digital camera that spits out GIF files. Why in the world would you want to dither your world down to 8-bit colour? And GD doesn't support animated gifs anyway. -R On Fri, 12 Apr 2002, fabwash wrote: +1 ! Agreed with GIF format, look at facelink.com, i'm sure 80% of the pictures uploaded there are from programs and cameras that default to GIF. I'm not really savy with graphics but isn't GIF the only format that allows for animated pictures? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Let's fork GD!
Title: RE: [PHP-DEV] Let's fork GD! Rasmus Lerdorf writes: Well, supporting writing regular GIF files is not something we can legally do. It is not us making the decision. There will definitely be no writing of LZW-GIF files in PHP. I am not willing to blatantly violate a patent that is being actively enforced. Will it still be possible to build PHP with external GD libs? Assuming that is the case, the issue is really moot. Bundling GD is a good idea; it'll make things much easier and much better for many people, which is a fundamental PHP approach. And I understand your trepidation entirely. Nobody wants a brouhaha with Unisys. Best Regards Mike Robinson IT/Developer - Torstar Media Group Television Phone: 416.945.8786 Fax: 416.869.4566 Email: [EMAIL PROTECTED] To find out more about what we can do for you, please visit us at: http://www.tmgtv.ca/ and http://www.thestar.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Let's fork GD!
Yes, the intention was never to remove the ability to link against the system GD lib. -Rasmus On Fri, 12 Apr 2002, Robinson, Mike wrote: Rasmus Lerdorf writes: Well, supporting writing regular GIF files is not something we can legally do. It is not us making the decision. There will definitely be no writing of LZW-GIF files in PHP. I am not willing to blatantly violate a patent that is being actively enforced. Will it still be possible to build PHP with external GD libs? Assuming that is the case, the issue is really moot. Bundling GD is a good idea; it'll make things much easier and much better for many people, which is a fundamental PHP approach. And I understand your trepidation entirely. Nobody wants a brouhaha with Unisys. Best Regards Mike Robinson IT/Developer - Torstar Media Group Television Phone: 416.945.8786 Fax: 416.869.4566 Email: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Thread safety global strings
Correct me if i am wrong: We have a macros that garantees thread safety for module globals TSRMG. But if we use this on strings or structures that is not thread safe because then the lock only occurs for copying the pointer. But another thread could change the global value what results in efree of the former copied pointer. If i am correct we would need: a) to generate an error if TSRMG is used on a string b) a function that allows to do a thread safe copy operation with the string. OR we make TSRMG do this and all current TSRMG calls with strings have to explicitly call free for the copy. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thread safety global strings
--- Marcus Boerger [EMAIL PROTECTED] wrote: Correct me if i am wrong: We have a macros that garantees thread safety for module globals TSRMG. But if we use this on strings or structures that is not thread safe because then the lock only occurs for copying the pointer. But another thread could change the global value what results in efree of the former copied pointer. If i am correct we would need: a) to generate an error if TSRMG is used on a string b) a function that allows to do a thread safe copy operation with the string. OR we make TSRMG do this and all current TSRMG calls with strings have to explicitly call free for the copy. From what i understand the other thread will have its own local copy of the global space. so on a free it will free its own copy. Its global per thread (httpd). And if you want a true global you need to use some kinda shared memory. - Brad __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
Hi, Well, as far as I understand it, simply reading an LZW compressed GIF would not violate the license. It is software that creates LZW-compressed GIF files that need to pay up. So, we could still support GIF and manipulate LZW-compressed files, but once we read it in and manipulate it, we would not be able to write out an LZW-compressed GIF. That means the GIF files created by PHP-GD would be much larger. Which is not a problem IMHO. Like said before, GIF should go away. The only reason to support GIF (for me at least) is to make it possible to migrate to other formats gradually, without breaking existing scripts. We still have users who use GIF output, and it would be nicer to say to them: migrate to PNG because it is more efficient, than: migrate to PNG *NOW* otherwise your site won't work anymore... Oh, yes, and a +1 from me on integrating GD! Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] OpenSSL doesn't work with ZE2
I get this error when I trying to compile PHP with ZendEngine 2.. Using todays CVS version (4.3).. /bin/sh libtool --silent --mode=compile gcc -I/root/PHP4/php4/ext/bcmath/libbcmath/src -Iext/openssl/ -I/root/PHP4/php4/ext/openssl/ -DPHP_ATOM_INC -I/root/PHP4/php4/include -I/root/PHP4/php4/main -I/root/PHP4/php4 -I/usr/local/www/httpd2/include -I/root/PHP4/php4/Zend -I/usr/include/freetype2/freetype -I/usr/local/www/mysql/include/mysql -I/usr/include/ucd-snmp -I/root/PHP4/php4/ext/xml/expat -D_REENTRANT -I/root/PHP4/php4/TSRM -g -O2 -pthread -DZTS -prefer-pic -c /root/PHP4/php4/ext/openssl/openssl.c -o ext/openssl/openssl.lo /root/PHP4/php4/ext/openssl/openssl.c: In function `add_assoc_name_entry': /root/PHP4/php4/ext/openssl/openssl.c:220: `tsrm_ls' undeclared (first use in this function) /root/PHP4/php4/ext/openssl/openssl.c:220: (Each undeclared identifier is reported only once /root/PHP4/php4/ext/openssl/openssl.c:220: for each function it appears in.) /root/PHP4/php4/ext/openssl/openssl.c: In function `php_openssl_make_REQ': /root/PHP4/php4/ext/openssl/openssl.c:1140: `tsrm_ls' undeclared (first use in this function) make: *** [ext/openssl/openssl.lo] Error 1 Don't know if this is the right list to send this too... Regards Magnus Määttä -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL doesn't work with ZE2
Patch going in right now... --Wez. On 12/04/02, Magnus Mtt [EMAIL PROTECTED] wrote: I get this error when I trying to compile PHP with ZendEngine 2.. Using todays CVS version (4.3).. /root/PHP4/php4/ext/openssl/openssl.c: In function `add_assoc_name_entry': /root/PHP4/php4/ext/openssl/openssl.c:220: `tsrm_ls' undeclared (first use in this function) /root/PHP4/php4/ext/openssl/openssl.c: In function `php_openssl_make_REQ': /root/PHP4/php4/ext/openssl/openssl.c:1140: `tsrm_ls' undeclared (first use in this function) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL doesn't work with ZE2
On 12/04/02, Magnus Mtt [EMAIL PROTECTED] wrote: I get this error when I trying to compile PHP with ZendEngine 2.. Using todays CVS version (4.3).. Fixed - thanks for reporting it. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main php_streams.h
Wez Furlong wrote: wez Fri Apr 12 14:17:20 2002 EDT Modified files: /php4/main php_streams.h Log: fix segfault Thanks Wez, that fixed it! -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
Hi, I don't, I don't! I don't like GIF, I'm just saying that unfortunately it's there! The Sony CD300 spits out animated GIFs and statics GIFs. Fab. From: Rasmus Lerdorf [EMAIL PROTECTED] To: fabwash [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Let's fork GD! Date: Fri, 12 Apr 2002 07:13:38 -0700 (PDT) I don't think I have ever seen a digital camera that spits out GIF files. Why in the world would you want to dither your world down to 8-bit colour? And GD doesn't support animated gifs anyway. -R On Fri, 12 Apr 2002, fabwash wrote: +1 ! Agreed with GIF format, look at facelink.com, i'm sure 80% of the pictures uploaded there are from programs and cameras that default to GIF. I'm not really savy with graphics but isn't GIF the only format that allows for animated pictures? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone wrote persistent variable extension?
On Thu, 11 Apr 2002, Steve Meyers wrote:
Here's another idea that I've floated the last couple weeks (this would be
especially good in the SRM and msession extensions), how about a method to
cache values? This is very similar to the application variables, except
that there would be a limit to how much was stored, and if that limit was
reached, the most infrequently used data would be discarded.
Right now I've got some lookups I have to do fairly often for country,
state/province, city of users. There are over 2 million cities in my
database, but the vast majority of them aren't used. I would like to be
able to store the most frequently used data in a persistent manner, but
there's really not the option of storing everything. So if it wasn't in
the persistent variable, I would look it up in the database, and then put
it into the persistent variable. The caching mechanism would then delete a
value if necessary, e.g. the least recently used.
You can already do this with SRM, by writing a Banana like:
?php
class Cache extends Banana
{
function init ($db)
{
$this-db = $db;
$this-cache = array();
}
function get_city ($city)
{
if (in_array ($city, array_keys ($this-cache))) {
return $this-cache[$city];
} else {
$r = mysql_query (select * from City where name =
'$city', $this-db);
$row = mysql_fetch_row ($r);
$this-cache[$city] = $row;
$this-cache[$city]['timestamp'] = date();
return $row;
}
/* purge old entries */
foreach ($this-cache as $key = $entry) {
if ($entry['timestamp'] date() - 3600) {
unset ($this-cache['timestamp']);
}
}
}
}
$banana = new Cache();
$banana-run();
?
Then call from your 'client' script:
?php
$srm = new SRM ('/var/srm.socket', );
$cache = new SRMApp ($srm, 'Cache');
$cache-init(mysql_connect ('localhost', 'user', 'password'));
$cache-get_city (Koln);
?
regards,
Derick
---
Did I help you? Consider a gift:
http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
---
PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New DOM 4.1.2 Documentation
Is there any detailed documentation or anyone I can contact for the new version of PHP DOM XML? I know this might not pertain to this mailing list,but I know the PHP DOM uses libxml and I would like to get in contact with the people who update this extension. It is very urgent as well asimportant. Recently as new versions of PHP have been released, the DOM extension in PHP keeps changing without updates to the documentation. It's listed asexperimental, but one of my questions is why haven't the developers just implemented it as it is found on many Java implementations? They seem to bere-inventing the wheel and making mistakes and I would like to help resolve these issues so that PHP developers can finally rely on it rather thanlooking for alternate solutions. Can anyone help out? With Kind Regards Thanks in Advance, Ken
[PHP-DEV] socket_get_status(...)
Hello Dev list, Has there been any progress, or are there plans to fix socket_get_status(...), recently? If so, I'll try it again, but I don't see it documented anywhere. See bug ID#15976 Thanks, S -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New DOM 4.1.2 Documentation
Hello Ken, the DOM documentation was just updated (today). It should show up in a few days at the web site. If you have more comments, please tell us. Derick On Fri, 12 Apr 2002, Ken Egervari wrote: Is there any detailed documentation or anyone I can contact for the new version of PHP DOM XML? I know this might not pertain to this mailing list, but I know the PHP DOM uses libxml and I would like to get in contact with the people who update this extension. It is very urgent as well as important. Recently as new versions of PHP have been released, the DOM extension in PHP keeps changing without updates to the documentation. It's listed as experimental, but one of my questions is why haven't the developers just implemented it as it is found on many Java implementations? They seem to be re-inventing the wheel and making mistakes and I would like to help resolve these issues so that PHP developers can finally rely on it rather than looking for alternate solutions. Can anyone help out? With Kind Regards Thanks in Advance, Ken --- Did I help you? Consider a gift: http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] The PHP Platform
Hello everyone, I think as we go forward with PHP and as PHP 5 is nearing, shouldn't we planning on developing a PHP Platform? Basically the Java or .NET Platform - a set of stable and well written class libraries in which everyone can use? Classes that make sense for every day and maybe not-so every day PHP development? With .NET and Java out there, PHP is really falling short. It's not even efficient to develop in any more other than that its tools are free. I tried to start such an initiative with eXtremePHP, but only 2 developers go so far. We need a community to help build a large platform that provides classes for everything a PHP developer might need. Why am I saying this? Well, looking at DOM XML, PHP still hasn't gotten it right. Even though there are several great implementations out there in other languages, PHP is slowly building towards those already bugged-out, well written designs. I was recently doing a project and now that PHP 4.1.2 has changed the DOM XML library without making any changes to the documentation, this move seriously messed up my work as well as many others. In my case, I have to use the latest version so I had to migrate a lot of code. I know that the library was considered experimental, but the design decisions were made poorly while they could have just emulated the w3c bindings which were already thought out and used across the world as far as Java and many other languages are concerned. I think the PHP developers and community should start moving towards a mature platform with an even larger goal in mind rather than just a set of functions. With the RAD tools provided by .NET and Java, PHP is giving less and less of a reason for capable developers to use the language because it really only solves the needs of HTML developers that need some dynamic functionality to their sites. I guess the future is in the hands of its leaders to make the right calls. It will be a test to see which calls are made. Ken
[PHP-DEV] Re: The PHP Platform
Ken Egervari [EMAIL PROTECTED] wrote: [ ... ] because it really only solves the needs of HTML developers that need some dynamic functionality to their sites. [ ... ] what's wrong with that? more generally, why do you expect the developers of php to provide the tools that you want, instead of the ones that they want? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
Ken Egervari [EMAIL PROTECTED] wrote: Hello everyone, I think as we go forward with PHP and as PHP 5 is nearing, shouldn't we planning on developing a PHP Platform? Basically the Java or .NET Platform - a set of stable and well written class libraries in which everyone can use? Classes that make sense for every day and maybe not-so every day PHP development? With .NET and Java out there, PHP is really falling short. It's not even efficient to develop in any more other than that its tools are free. I tried to start such an initiative with eXtremePHP, but only 2 developers go so far. We need a community to help build a large platform that provides classes for everything a PHP developer might need. http://pear.php.net/ -- Richard Heyes -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
My post was trying to convey that it takes time to do things that *every* developer does. It's not a question whether the developers want them or not, because I'm sure they would. The real issue is that was not one of the goals of PHP and I'm trying to say that now it should be. The tools I'm talking about are not very specific things. Have you ever programmed in Java or .NET? If you have, you'd see that the platform is more sophisticated and powerful, but yet it's actually even getting easier to use. Go to www.extremephp.org and see what I was trying to do. These are things that every developer would learn to use and like as they utilize PHP. Some of these things should be in the core language. The real issue is that PHP needs to take advantage of reuse. The PEAR project and others aren't doing that. For instance, why should I use PHP for an enterprise application when it takes me 3 times as long to make my data layer (assuming I don't have extremephp installed) compared to other technologies? It shouldn't. This is not a post about, Hey, I'm lazy and I want you PHP guys to make everything I need. That's silly. If you look at the code base that I give out freely (plus other things I've done), you can call that far from lazy. I actually find your post rather immature as well assuming that I just want free custom tools. I think you need yourself need think to think about software reuse and improving productivity. It's an important software issue now as it was 20 years ago and I don't see PHP making any leaps towards that. I'm merely stating that it should start to play catchup now, especially with PHP 5 being in development. Regards, Ken - Original Message - From: Jim Winstead [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 12, 2002 4:41 PM Subject: [PHP-DEV] Re: The PHP Platform Ken Egervari [EMAIL PROTECTED] wrote: [ ... ] because it really only solves the needs of HTML developers that need some dynamic functionality to their sites. [ ... ] what's wrong with that? more generally, why do you expect the developers of php to provide the tools that you want, instead of the ones that they want? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
Hello Richard, I don't think people really understand me correctly. Pear is small in comparison to the Java Platform or the .NET Framework. My library extremephp.org is probably around 4-5 times bigger than PEAR and it's not even close to being finished yet. There could be much more to develop to make PHP an even greater language to use, but it's not keeping up. Ken - Original Message - From: Richard Heyes [EMAIL PROTECTED] To: Ken Egervari [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, April 12, 2002 4:45 PM Subject: Re: [PHP-DEV] The PHP Platform Ken Egervari [EMAIL PROTECTED] wrote: Hello everyone, I think as we go forward with PHP and as PHP 5 is nearing, shouldn't we planning on developing a PHP Platform? Basically the Java or .NET Platform - a set of stable and well written class libraries in which everyone can use? Classes that make sense for every day and maybe not-so every day PHP development? With .NET and Java out there, PHP is really falling short. It's not even efficient to develop in any more other than that its tools are free. I tried to start such an initiative with eXtremePHP, but only 2 developers go so far. We need a community to help build a large platform that provides classes for everything a PHP developer might need. http://pear.php.net/ -- Richard Heyes -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
From you message, it seems like PEAR is finished. PEAR is hardly a beta and IMHO will never be 'finished'. Tal _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
Ken,
Many classes and for Java .NET and even php very own PEAR are libraries of
bloat. They offer some functionality and in exchange take away tremendous
amount of extra resources. That is not to say all those classes and libraries
are written poorly, many are not, however no matter how good is a wrapper it
will always add slowdowns.
In php (at least 4.X) loading large classes to memory is VERY memory cosuming
and loading huge libraries will put a large strain on system with medium to
heavy use.
Most people do not need PEAR or other assistance libraries for most of their
code, especially in PHP where standard functions are VERY easy to use and
their is a function for almost every occasion :)
In many cases, like with database layers you can avoid class by simply using:
$db_type = 'mysql_'; or $db_type('pg_'); etc...
and then calling php's database manipulation functions with $db_type prefix.
So, in my opinion creating class libraries is counter productive in PHP
enviroment. It makes sence in C C++ to some degree where to open a socket
you need to do a good deal of work, so a class which accepts a socket
domain and returns open socket may be very useful. But in PHP where
everything is already done for you there is little need for that IMHO.
On April 12, 2002 04:53 pm, Ken Egervari wrote:
Hello Richard,
I don't think people really understand me correctly. Pear is small in
comparison to the Java Platform or the .NET Framework. My library
extremephp.org is probably around 4-5 times bigger than PEAR and it's not
even close to being finished yet. There could be much more to develop to
make PHP an even greater language to use, but it's not keeping up.
--
Ilia Alshanetsky
FUDforum Developer
http://fud.prohost.org/forum/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
Although your
arguments make sense for speed, this is tradeoff that manyprogrammers are
willing to take. As for taking "tons of time to load",although I have
noticed a large slowdown, it's not critical and nothing abetter server can't
solve if it does become critical.I'd rather develop a website in half
the time and spend more money on aserver than do it slower and harder.
No one wants to work hard.As for the data layer, I think simple calls
like that don't constitute adata layer at all. You still might have
database code all over the website,and many of the related things
likeadding/updating/deleting/searching/whatever on a single entity can be
acrossseveral pages. In my library, I have a concept called "Data
AccessObjects". It makes development of the data layer very easy -
almostmindless as a matter of fact - and I can actually create an entire
tier thatcompletely decouples database calls from application logic
completely. Thisis something pear doesn't do and I think this is
essential for webpagesbecause a) they need to change all the time b)
database code, php code andhtml code on the same page is messy c) this is
how large enterprise systemsneed to be built.I think that should
give you an explanation on why PHP still needs todevelop. If not, then
PHP should outright states its goals and intentionsto everyone because
people like myself who are waiting for things to moveforward (because we
have a lot of code invested into the language already)want to move forward
with it. That just isn't happening from my point ofview.To
argue your point about performance, look at any emerging technology inthe
past. History has shown that coming up with the technical solution
thatworks and solves people's problem is essential. Once something is
in place,then we start looking at how to speed it up. But if we don't
even get tothe point of it working and solving people's problems, then we
aren't goinganyway.Regards,Ken- Original Message
-From: "Ilia A." [EMAIL PROTECTED]To: "Ken Egervari" [EMAIL PROTECTED];
"Richard Heyes"[EMAIL PROTECTED]; [EMAIL PROTECTED]Sent: Friday, April 12, 2002 5:48 PMSubject: Re: [PHP-DEV]
The PHP Platform Ken, Many classes and for Java
.NET and even php very own PEAR are librariesof bloat. They
offer some functionality and in exchange take away tremendous amount of
extra resources. That is not to say all those classes andlibraries
are written poorly, many are not, however no matter how good is a
wrapperit will always add slowdowns. In php (at least 4.X)
loading large classes to memory is VERY memorycosuming and loading
huge libraries will put a large strain on system with mediumto heavy
use. Most people do not need PEAR or other assistance libraries for most
oftheir code, especially in PHP where standard functions are VERY
easy to use and their is a function for almost every occasion :)
In many cases, like with database layers you can avoid class by
simplyusing: $db_type = 'mysql_'; or $db_type('pg_');
etc... and then calling php's database manipulation functions with
$db_typeprefix. So, in my opinion creating class libraries
is counter productive in PHP enviroment. It makes sence in C C++
to some degree where to open asocket you need to do a good deal of
work, so a class which accepts a socket domain and returns open
socket may be very useful. But in PHP where everything is already done
for you there is little need for that IMHO. On April 12, 2002
04:53 pm, Ken Egervari wrote: Hello Richard,
I don't think people really understand me correctly. Pear is small
in comparison to the Java Platform or the .NET Framework. My
library extremephp.org is probably around 4-5 times bigger than
PEAR and it'snot even close to being finished yet. There
could be much more to developto make PHP an even greater
language to use, but it's not keeping up.
-- Ilia Alshanetsky FUDforum Developer http://fud.prohost.org/forum/
Re: [PHP-DEV] The PHP Platform
I agree with you friend. Everything is always in beta as far as I amconcerned. Everything evolves. But PEAR has been around for how long now?I think its time it started to evolve a little faster and its goals bere-evaluated. When PHP 5 supports a simular language like Java, there isgoing to be nothing to build from.- Original Message -From: "Tal Peer" [EMAIL PROTECTED]To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]Sent: Friday, April 12, 2002 5:32 PMSubject: Re: [PHP-DEV] The PHP Platform From you message, it seems like PEAR is finished. PEAR is hardly a betaand IMHO will never be 'finished'. Tal _ Get your FREE download of MSN Explorer athttp://explorer.msn.com/intl.asp.
Re: [PHP-DEV] Re: The PHP Platform
Ken Egervari [EMAIL PROTECTED] wrote: I actually find your post rather immature as well assuming that I just want free custom tools. I think you need yourself need think to think about software reuse and improving productivity. It's an important software issue now as it was 20 years ago and I don't see PHP making any leaps towards that. I'm merely stating that it should start to play catchup now, especially with PHP 5 being in development. i didn't assume you wanted free custom tools. i guess i overstated my point a bit. let me try to rephrase: why should we work on your grand vision for php's future, instead of the one that we are already collectively following? keep in mind that the following are tremendously lousy reasons: 1. sun and microsoft are doing it. 2. people who aren't already using php won't use php if we don't. 3. people already using php won't use php anymore if we don't. i think you need to learn more about how an open source community functions. how it sets priorities, how it communicates, and how it achieves progress. your we-must-do-this sort of diktat is a futile approach. as to my own feelings of the value of reuse and improving productivity, perhaps i see more value in reusing the components available in the java and .net platforms through technologies like soap, ext/java, and ext/dotnet, rather than cloning them in php. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
At 22:01 12/04/2002 +, Jim Winstead wrote: as to my own feelings of the value of reuse and improving productivity, perhaps i see more value in reusing the components available in the java and .net platforms through technologies like soap, ext/java, and ext/dotnet, rather than cloning them in php. I disagree. I doubt many people will use ext/dotnet and ext/java to use technologies. People don't like to spread themselves into too many technologies. They will most likely use a full-blown dotnet or java solution. I think it is important for PHP to fill the gaps in a few areas including web services. I am not sure how well know Pear is (I assume most of this stuff would be done in Pear) but it'd make sense to at some point push PHP+Pear as the PHP Platform giving solutions for things dotnet and java give. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
Usually that if it ain't broke, don't fix it attritude is just the thing to make a technology less and less useful and eventually it'll be antiquated. Eseentially, it is already is. Don't get me wrong, just because it's out of date doesn't mean it still isn't useful. I just think that even in an opensource community, there would be leaders and people looking towards the future. As for your comments on .NET and Java extensions, if i wanted to use those technologies, I would use them for everything. If someone is using .net, they are probably taking advantage of all the other cool features that it provides. Like I said, I think its time PHP started moving forward and developed a new vision for itself and the community. Ken - Original Message - From: Jim Winstead [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 12, 2002 6:01 PM Subject: Re: [PHP-DEV] Re: The PHP Platform Ken Egervari [EMAIL PROTECTED] wrote: I actually find your post rather immature as well assuming that I just want free custom tools. I think you need yourself need think to think about software reuse and improving productivity. It's an important software issue now as it was 20 years ago and I don't see PHP making any leaps towards that. I'm merely stating that it should start to play catchup now, especially with PHP 5 being in development. i didn't assume you wanted free custom tools. i guess i overstated my point a bit. let me try to rephrase: why should we work on your grand vision for php's future, instead of the one that we are already collectively following? keep in mind that the following are tremendously lousy reasons: 1. sun and microsoft are doing it. 2. people who aren't already using php won't use php if we don't. 3. people already using php won't use php anymore if we don't. i think you need to learn more about how an open source community functions. how it sets priorities, how it communicates, and how it achieves progress. your we-must-do-this sort of diktat is a futile approach. as to my own feelings of the value of reuse and improving productivity, perhaps i see more value in reusing the components available in the java and .net platforms through technologies like soap, ext/java, and ext/dotnet, rather than cloning them in php. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] Let's fork GD!
Hi, Yes, the intention was never to remove the ability to link against the system GD lib. -Rasmus why not replace GD by imagemagick which is better anyway? http://www.imagemagick.org http://pear.php.net/manual/en/pecl.imagick.php -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
ext/gd is more popular then imagick. And, seriously, I wouldn't use imagick if I've read the code carefully. It's not yet production quality. On Sat, Apr 13, 2002 at 12:54:11AM +0200, Daniel Lorch wrote : Hi, Yes, the intention was never to remove the ability to link against the system GD lib. -Rasmus why not replace GD by imagemagick which is better anyway? http://www.imagemagick.org http://pear.php.net/manual/en/pecl.imagick.php -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Mind if I MFH ? What QA did you do on it? the usual? ah... none :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] Let's fork GD!
why not replace GD by imagemagick which is better anyway? Have you looked under the skirts of ImageMagick? It is one of the poorest-written libraries I have seen. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
Ken Egervari wrote: I agree with you friend. Everything is always in beta as far as I am concerned. Everything evolves. But PEAR has been around for how long now? I think its time it started to evolve a little faster and its goals be re-evaluated. When PHP 5 supports a simular language like Java, there is going to be nothing to build from. So why are you making a library to compete with PEAR, instead of contributing all of your classes to PEAR? This is open source, after all, you can make a difference in the development of PEAR. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
Well, my library does compete with PEAR considering that it replaces some of their things. My library is also open-source and I've told them they can add them and they never did. In fact, I wanted that to happen since that would provide more tools to everyone. - Original Message - From: Steve Meyers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 12, 2002 7:22 PM Subject: Re: [PHP-DEV] The PHP Platform Ken Egervari wrote: I agree with you friend. Everything is always in beta as far as I am concerned. Everything evolves. But PEAR has been around for how long now? I think its time it started to evolve a little faster and its goals be re-evaluated. When PHP 5 supports a simular language like Java, there is going to be nothing to build from. So why are you making a library to compete with PEAR, instead of contributing all of your classes to PEAR? This is open source, after all, you can make a difference in the development of PEAR. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
On Fri, 2002-04-12 at 22:31, Ken Egervari wrote: Hello everyone, I think as we go forward with PHP and as PHP 5 is nearing, shouldn't we planning on developing a PHP Platform? Basically the Java or .NET Platform - a set of stable and well written class libraries in which everyone can use? Classes that make sense for every day and maybe not-so every day PHP development? With .NET and Java out there, PHP is really falling short. It's not even efficient to develop in any more other than that its tools are free. I tried to start such an initiative with eXtremePHP, but only 2 developers go so far. We need a community to help build a large platform that provides classes for everything a PHP developer might need. Why am I saying this? Well, looking at DOM XML, PHP still hasn't gotten it right. Even though there are several great implementations out there in other languages, PHP is slowly building towards those already bugged-out, well written designs. I was recently doing a project and now that PHP 4.1.2 has changed the DOM XML library without making any changes to the documentation, this move seriously messed up my work as well as many others. In my case, I have to use the latest version so I had to migrate a lot of code. I know that the library was considered experimental, but the design decisions were made poorly while they could have just emulated the w3c bindings which were already thought out and used across the world as far as Java and many other languages are concerned. I think the PHP developers and community should start moving towards a mature platform with an even larger goal in mind rather than just a set of functions. With the RAD tools provided by .NET and Jav! a, PHP is giving less and less of a reason for capable developers to use the language because it really only solves the needs of HTML developers that need some dynamic functionality to their sites. I guess the future is in the hands of its leaders to make the right calls. It will be a test to see which calls are made. I agree that PHP needs a platform like you mention. Today, PHP has a zillion extensions each providing nice functionality, but there is very little interoperability between extensions. For example, none of the XML-related extensions (domxml, xslt, xml) are able to interoperate. If PHP had a good platform, you could take part of your DOM tree and use the xslt extension to render it. Not to mention the all-different database extensions. Wez took a great first step by implemting PHP streams. This is the kind of integration we need. There are lots of other things we can do add sudden reusability in many parts of PHP, such as a common C API to database extensions, an abstracted type system that can map data more easily between SQL databases, HTML forms, Web Services etc., flexible exception handling and so on. PEAR does not offer this today, but it offers the infrastructure necessary to build and deploy such a platform (PEAR is a lot more than a bunch of classes). My intent is to bundle core PEAR packages into the PFC (PHP Foundation Classes). PFC is just the platform you are calling for. Until now I have focused my energy on building the PEAR infrastructure, so people such as yourself can go ahead and make the platform. If you already have written a lot of code, we should definitely work together. Today the PEAR installer is self-maintainable, it's able to update itself from the web, which is good enough for me to be comfortable releasing it. PHP 4.2.0 will contain a self-maintainable PEAR installer, and 4.3.0 will go one step further and bundle package tarballs instead of plan .php files. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
Well, your libraries probably don't meet the coding standards for PEAR right now, and would need a small amount of work to add the necessary hooks to make it compatible. http://pear.php.net/faq.php#faq-2 With all that code you've got, it should be fairly trivial for you to become a PEAR contributor and even get your own CVS account. It's all in how you approach it. If you just come in and tell everyone that they suck, and your ideas and code are so much better, you'll find that most people will not listen to you. If you come in and say, Hey I've got some classes I've been working on, what do I have to do to contribute them to PEAR and get a CVS account?, you'll find that people will jump through hoops to help you out. Ken Egervari wrote: Well, my library does compete with PEAR considering that it replaces some of their things. My library is also open-source and I've told them they can add them and they never did. In fact, I wanted that to happen since that would provide more tools to everyone. - Original Message - From: Steve Meyers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 12, 2002 7:22 PM Subject: Re: [PHP-DEV] The PHP Platform Ken Egervari wrote: I agree with you friend. Everything is always in beta as far as I am concerned. Everything evolves. But PEAR has been around for how long now? I think its time it started to evolve a little faster and its goals be re-evaluated. When PHP 5 supports a simular language like Java, there is going to be nothing to build from. So why are you making a library to compete with PEAR, instead of contributing all of your classes to PEAR? This is open source, after all, you can make a difference in the development of PEAR. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] socket_get_status(...)
Hi Sean, socket_get_status is unlikely to ever work with socket resources from the sockets extension. You should be using things like the select() function to test the status of your sockets if you are dealing with them on such a low level. --Wez. On 12/04/02, Sean Coates [EMAIL PROTECTED] wrote: Hello Dev list, Has there been any progress, or are there plans to fix socket_get_status(...), recently? If so, I'll try it again, but I don't see it documented anywhere. See bug ID#15976 Thanks, S -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
The great thing about PHP is that it's basic. It's like C, a basic language structure, with some basic libraries. Then you add extensions to it, you don't have to use them. I don't know of any programmer that is satisfied with everything that is included in one language. Java is great, but I would like to be able to use some of the GD extensions for it, and I can't. With PHP I can write an extensions and poof, there you go. Agreed, there are some problems with changes in the php code that break things, documentation problems, but that's a QA/Doc issue, and the community, the QA folks, the Documentation people are working hard on improving this. We could do like Java and add zillions of procedures to do everything, but you know very well that we would still find programmers that complain that we didn't include this foo or that bar. You can contribute to improving the PHP code, either by submitting new extensions, or by submitting PHP code in the PEAR library. I don't think anyone here would deny anything you submit, as long as it respects the PHP coding standards, PEAR coding standards, and doesn't break things. The people that contribute to PHP are very open, and your contributions are very welcome. Do not forget, however, that PHP is open source, not like Java or .NET, that the PHP core development team is about 20 people, that the QA folks are trying their best to keep things working and are also working on stronger regression tests, that PHP support is voluntary, and that we don't get a cent ($ or euro, same) for what we contribute here. We need people like you to improve the code, the standards, the libraries, but we need people like you to contribute, not just complain (argh, i'm asking for trouble). I've convinced my company today that we should ensure that our ODBC API is compatible with the PHP unified ODBC, do some tests, and update our code or the .h php headers if necessary. I'm working on adding support for our proprietary procedures to php to allow it to access our proprietary file system. I can't wait to see your contribution to the php code and procedures so that PHP becomes your prefered language compared to Java. Fab. - Original Message - From: Ken Egervari [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 12, 2002 6:42 PM Subject: Re: [PHP-DEV] Re: The PHP Platform Usually that if it ain't broke, don't fix it attritude is just the thing to make a technology less and less useful and eventually it'll be antiquated. Eseentially, it is already is. Don't get me wrong, just because it's out of date doesn't mean it still isn't useful. I just think that even in an opensource community, there would be leaders and people looking towards the future. As for your comments on .NET and Java extensions, if i wanted to use those technologies, I would use them for everything. If someone is using .net, they are probably taking advantage of all the other cool features that it provides. Like I said, I think its time PHP started moving forward and developed a new vision for itself and the community. Ken - Original Message - From: Jim Winstead [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 12, 2002 6:01 PM Subject: Re: [PHP-DEV] Re: The PHP Platform Ken Egervari [EMAIL PROTECTED] wrote: I actually find your post rather immature as well assuming that I just want free custom tools. I think you need yourself need think to think about software reuse and improving productivity. It's an important software issue now as it was 20 years ago and I don't see PHP making any leaps towards that. I'm merely stating that it should start to play catchup now, especially with PHP 5 being in development. i didn't assume you wanted free custom tools. i guess i overstated my point a bit. let me try to rephrase: why should we work on your grand vision for php's future, instead of the one that we are already collectively following? keep in mind that the following are tremendously lousy reasons: 1. sun and microsoft are doing it. 2. people who aren't already using php won't use php if we don't. 3. people already using php won't use php anymore if we don't. i think you need to learn more about how an open source community functions. how it sets priorities, how it communicates, and how it achieves progress. your we-must-do-this sort of diktat is a futile approach. as to my own feelings of the value of reuse and improving productivity, perhaps i see more value in reusing the components available in the java and .net platforms through technologies like soap, ext/java, and ext/dotnet, rather than cloning them in php. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List
Re: [PHP-DEV] Re: The PHP Platform
Ken Egervari [EMAIL PROTECTED] wrote: Usually that if it ain't broke, don't fix it attritude is just the thing to make a technology less and less useful and eventually it'll be antiquated. Eseentially, it is already is. Don't get me wrong, just because it's out of date doesn't mean it still isn't useful. I just think that even in an opensource community, there would be leaders and people looking towards the future. so, should we gather the cardinals and elect you pope now? Like I said, I think its time PHP started moving forward and developed a new vision for itself and the community. yes! the new build system that sascha introduced wasn't a move forward. stig (and the large cast of others) working on building the pear infrastructure aren't moving forward. rasmus is standing firm as he looks at integrating the gd library more tightly into php. andi (and others) are blocking progress with all that work on the new zend engine. i wish derick and jani would stop building things like the build tracker at qa.php.net to make the qa process go smoother. i wish yasuo would stop working on the postgresql and session extensions and just give it a rest. that crazy andrei, creating things like the aggregate and overload extensions -- he needs to stop holding us back! don't get me started about wez and all that damn streams stuff! (do i need to continue?) people *are* looking forward. they're leading with code. what do you think we're doing here? waiting around for someone to tell us what to do? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 /sapi/apache config.m4 /sapi/apache2filter config.m4
Jani Taskinen [EMAIL PROTECTED] wrote: sniper Fri Apr 12 18:59:07 2002 EDT Modified files: /php4/sapi/apache config.m4 /php4/sapi/apache2filterconfig.m4 Log: - Added checks to prevent building the DSO with wrong configure option. woohoo! but what about --with-apache? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
Cool! This is about as worked up as I have ever seen Jim. ;) -Rasmus On 13 Apr 2002, Jim Winstead wrote: Ken Egervari [EMAIL PROTECTED] wrote: Usually that if it ain't broke, don't fix it attritude is just the thing to make a technology less and less useful and eventually it'll be antiquated. Eseentially, it is already is. Don't get me wrong, just because it's out of date doesn't mean it still isn't useful. I just think that even in an opensource community, there would be leaders and people looking towards the future. so, should we gather the cardinals and elect you pope now? Like I said, I think its time PHP started moving forward and developed a new vision for itself and the community. yes! the new build system that sascha introduced wasn't a move forward. stig (and the large cast of others) working on building the pear infrastructure aren't moving forward. rasmus is standing firm as he looks at integrating the gd library more tightly into php. andi (and others) are blocking progress with all that work on the new zend engine. i wish derick and jani would stop building things like the build tracker at qa.php.net to make the qa process go smoother. i wish yasuo would stop working on the postgresql and session extensions and just give it a rest. that crazy andrei, creating things like the aggregate and overload extensions -- he needs to stop holding us back! don't get me started about wez and all that damn streams stuff! (do i need to continue?) people *are* looking forward. they're leading with code. what do you think we're doing here? waiting around for someone to tell us what to do? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] socket_get_status(...)
Wez Furlong wrote: Hi Sean, socket_get_status is unlikely to ever work with socket resources from the sockets extension. You should be using things like the select() function to test the status of your sockets if you are dealing with them on such a low level. --Wez. This is a documentation problem then. If you go to the socket_get_status() page, it says to see also a bunch of functions from the socket extension, with no mention of fsockopen(), the only function it works with. On several of the socket extension manual pages, they say to see also socket_get_status(). From the docs, it sure looks like it's supposed to work with them. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: The PHP Platform
That's probably the most civilized flame I've ever read. I'm impressed! -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 6:50 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: The PHP Platform Cool! This is about as worked up as I have ever seen Jim. ;) -Rasmus On 13 Apr 2002, Jim Winstead wrote: Ken Egervari [EMAIL PROTECTED] wrote: Usually that if it ain't broke, don't fix it attritude is just the thing to make a technology less and less useful and eventually it'll be antiquated. Eseentially, it is already is. Don't get me wrong, just because it's out of date doesn't mean it still isn't useful. I just think that even in an opensource community, there would be leaders and people looking towards the future. so, should we gather the cardinals and elect you pope now? Like I said, I think its time PHP started moving forward and developed a new vision for itself and the community. yes! the new build system that sascha introduced wasn't a move forward. stig (and the large cast of others) working on building the pear infrastructure aren't moving forward. rasmus is standing firm as he looks at integrating the gd library more tightly into php. andi (and others) are blocking progress with all that work on the new zend engine. i wish derick and jani would stop building things like the build tracker at qa.php.net to make the qa process go smoother. i wish yasuo would stop working on the postgresql and session extensions and just give it a rest. that crazy andrei, creating things like the aggregate and overload extensions -- he needs to stop holding us back! don't get me started about wez and all that damn streams stuff! (do i need to continue?) people *are* looking forward. they're leading with code. what do you think we're doing here? waiting around for someone to tell us what to do? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
The issue I have with PHP is that the people in charge have reasons for not
implementing performance enhancements in the base code. They charge a fair
amount for add-ons that increases performance drastically. I could
actually argue that extensibility and performance on the back end aren't
what they should be for this reason.
Not that I want to make enemies here, but I think this is a realistic
criticism. Not to mention that the Qt license that is used prevents anyone
from making extensions and selling them w/o an additional license from the
Zend people. So they are able to make money off of the hard work of all of
the module contributors, which I think really blows.
I really enjoy using PHP. I think the authors have done a commendible job.
I just wish that it was more open.
Medvitz
Ken Egervari wrote:
Although your arguments make sense for speed, this is tradeoff that many
programmers are willing to take. As for taking tons of time to load,
although I have noticed a large slowdown, it's not critical and nothing a
better server can't solve if it does become critical.
I'd rather develop a website in half the time and spend more money on a
server than do it slower and harder. No one wants to work hard.
As for the data layer, I think simple calls like that don't constitute a
data layer at all. You still might have database code all over the
website, and many of the related things like
adding/updating/deleting/searching/whatever on a single entity can be
across
several pages. In my library, I have a concept called Data Access
Objects. It makes development of the data layer very easy - almost
mindless as a matter of fact - and I can actually create an entire tier
that
completely decouples database calls from application logic completely.
This is something pear doesn't do and I think this is essential for
webpages because a) they need to change all the time b) database code, php
code and html code on the same page is messy c) this is how large
enterprise systems need to be built.
I think that should give you an explanation on why PHP still needs to
develop. If not, then PHP should outright states its goals and intentions
to everyone because people like myself who are waiting for things to move
forward (because we have a lot of code invested into the language already)
want to move forward with it. That just isn't happening from my point of
view.
To argue your point about performance, look at any emerging technology in
the past. History has shown that coming up with the technical solution
that
works and solves people's problem is essential. Once something is in
place,
then we start looking at how to speed it up. But if we don't even get to
the point of it working and solving people's problems, then we aren't
going anyway.
Regards,
Ken
- Original Message -
From: Ilia A. [EMAIL PROTECTED]
To: Ken Egervari [EMAIL PROTECTED]; Richard Heyes
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, April 12, 2002 5:48 PM
Subject: Re: [PHP-DEV] The PHP Platform
Ken,
Many classes and for Java .NET and even php very own PEAR are libraries
of
bloat. They offer some functionality and in exchange take away tremendous
amount of extra resources. That is not to say all those classes and
libraries
are written poorly, many are not, however no matter how good is a wrapper
it
will always add slowdowns.
In php (at least 4.X) loading large classes to memory is VERY memory
cosuming
and loading huge libraries will put a large strain on system with medium
to
heavy use.
Most people do not need PEAR or other assistance libraries for most of
their
code, especially in PHP where standard functions are VERY easy to use and
their is a function for almost every occasion :)
In many cases, like with database layers you can avoid class by simply
using:
$db_type = 'mysql_'; or $db_type('pg_'); etc...
and then calling php's database manipulation functions with $db_type
prefix.
So, in my opinion creating class libraries is counter productive in PHP
enviroment. It makes sence in C C++ to some degree where to open a
socket
you need to do a good deal of work, so a class which accepts a socket
domain and returns open socket may be very useful. But in PHP where
everything is already done for you there is little need for that IMHO.
On April 12, 2002 04:53 pm, Ken Egervari wrote:
Hello Richard,
I don't think people really understand me correctly. Pear is small in
comparison to the Java Platform or the .NET Framework. My library
extremephp.org is probably around 4-5 times bigger than PEAR and it's
not
even close to being finished yet. There could be much more to develop
to
make PHP an even greater language to use, but it's not keeping up.
--
Ilia Alshanetsky
FUDforum Developer
http://fud.prohost.org/forum/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
Re: [PHP-DEV] The PHP Platform
I've been looking at some of the files on LXR.php.net when I noticed that
as of Dec, Zend is no longer using the QPL. I apologize for posting not
knowing all of the facts, but the QPL license is included in the 4.1.2
source package, and that is what I was using as a basis.
Medvitz
Medvitz wrote:
The issue I have with PHP is that the people in charge have reasons for
not
implementing performance enhancements in the base code. They charge a
fair
amount for add-ons that increases performance drastically. I could
actually argue that extensibility and performance on the back end aren't
what they should be for this reason.
Not that I want to make enemies here, but I think this is a realistic
criticism. Not to mention that the Qt license that is used prevents
anyone from making extensions and selling them w/o an additional license
from the
Zend people. So they are able to make money off of the hard work of all
of the module contributors, which I think really blows.
I really enjoy using PHP. I think the authors have done a commendible
job.
I just wish that it was more open.
Medvitz
Ken Egervari wrote:
Although your arguments make sense for speed, this is tradeoff that many
programmers are willing to take. As for taking tons of time to load,
although I have noticed a large slowdown, it's not critical and nothing a
better server can't solve if it does become critical.
I'd rather develop a website in half the time and spend more money on a
server than do it slower and harder. No one wants to work hard.
As for the data layer, I think simple calls like that don't constitute a
data layer at all. You still might have database code all over the
website, and many of the related things like
adding/updating/deleting/searching/whatever on a single entity can be
across
several pages. In my library, I have a concept called Data Access
Objects. It makes development of the data layer very easy - almost
mindless as a matter of fact - and I can actually create an entire tier
that
completely decouples database calls from application logic completely.
This is something pear doesn't do and I think this is essential for
webpages because a) they need to change all the time b) database code,
php code and html code on the same page is messy c) this is how large
enterprise systems need to be built.
I think that should give you an explanation on why PHP still needs to
develop. If not, then PHP should outright states its goals and
intentions to everyone because people like myself who are waiting for
things to move forward (because we have a lot of code invested into the
language already)
want to move forward with it. That just isn't happening from my point of
view.
To argue your point about performance, look at any emerging technology in
the past. History has shown that coming up with the technical solution
that
works and solves people's problem is essential. Once something is in
place,
then we start looking at how to speed it up. But if we don't even get to
the point of it working and solving people's problems, then we aren't
going anyway.
Regards,
Ken
- Original Message -
From: Ilia A. [EMAIL PROTECTED]
To: Ken Egervari [EMAIL PROTECTED]; Richard Heyes
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, April 12, 2002 5:48 PM
Subject: Re: [PHP-DEV] The PHP Platform
Ken,
Many classes and for Java .NET and even php very own PEAR are
libraries
of
bloat. They offer some functionality and in exchange take away
tremendous amount of extra resources. That is not to say all those
classes and
libraries
are written poorly, many are not, however no matter how good is a
wrapper
it
will always add slowdowns.
In php (at least 4.X) loading large classes to memory is VERY memory
cosuming
and loading huge libraries will put a large strain on system with medium
to
heavy use.
Most people do not need PEAR or other assistance libraries for most of
their
code, especially in PHP where standard functions are VERY easy to use
and their is a function for almost every occasion :)
In many cases, like with database layers you can avoid class by simply
using:
$db_type = 'mysql_'; or $db_type('pg_'); etc...
and then calling php's database manipulation functions with $db_type
prefix.
So, in my opinion creating class libraries is counter productive in PHP
enviroment. It makes sence in C C++ to some degree where to open a
socket
you need to do a good deal of work, so a class which accepts a socket
domain and returns open socket may be very useful. But in PHP where
everything is already done for you there is little need for that IMHO.
On April 12, 2002 04:53 pm, Ken Egervari wrote:
Hello Richard,
I don't think people really understand me correctly. Pear is small in
comparison to the Java Platform or the .NET Framework. My library
extremephp.org is probably around 4-5 times bigger than PEAR and it's
Re: [PHP-DEV] Anyone wrote persistent variable extension?
I'm currently looking into an extension that would allow both persistent variables, as well as persistent functions. At this point I'm still going through the internals to determine the feasibility of such an extension. I'll keep you posted. BTW. If anyone knows what the refcount property of the zend_op_array is used for.. please email me. Medvitz Yasuo Ohgaki wrote: Edin Kadribasic wrote: I'm using sysvshm and sysvsem for this sort of things. It did provide dramatic speed difference with a static array of some 130 KB. However sysvshm extension does not work on win32. I don't know if shmop works on that platform. I know there is sysvshm. But, I don't actually used the module, yet. So correct me if I'm wrong. I think you are using serialize()/unserialize() to save data, right? I would like to get rid of serialize()/unserialize() also. Since, I have large web site that has relatively large menu definition as array. unserialize() needs about 0.4 sec for 1MB serialized data on Celeron 466/linux. (It's a array of about 2000 elements) Production machine is much faster but it makes a lot slower loading data with unserialize() for sure. If you can make portable way of introducing $_PERSISTENT I'm all for it. If not, I have very little to gain over using sysvshm extension directly. I might be missing something. Please let me know if I do. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] setlocale
Hi all, my browser (IE6) sends en-us in the HTTP_ACCEPT_LANGUAGE instead of the usual en_US. Would it be a good idea tomodifysetlocale (in ext/standard/string.c) so that it upshifts what is after the "-" before calling the local setlocale, or do you think that should be done by the user? Fab.
Re: [PHP-DEV] setlocale
Interesting, I noticed this too. I would favour first to check why Microsoft uses a '-' instead of '_' and if the mapping to the locales really is always the same except the '-'. - Markus ps: I don't think this sort of check/hack belongs into PHP; not without further investigation at least. On Sat, Apr 13, 2002 at 12:04:55AM -0400, fabwash wrote : Hi all, my browser (IE6) sends en-us in the HTTP_ACCEPT_LANGUAGE instead of the usual en_US. Would it be a good idea to modify setlocale (in ext/standard/string.c) so that it upshifts what is after the - before calling the local setlocale, or do you think that should be done by the user? Fab. -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Mind if I MFH ? What QA did you do on it? the usual? ah... none :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] T1lib thread safety
While doing some testing with Apache 2.0.35+PHP4.2.0RC3 I'm getting random crashes in T1_LoadFont(). Looking through the t1lib source (v1.3.1) I see frequent use of global variables which suggests it isn't thread safe. Is this a known problem? Maybe some mutexes in GD would help -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T1lib thread safety
Just the tip of the iceberg. There are a bunch of libraries that PHP can talk to that are not threadsafe. It's going to take a while before Apache2+PHP is going to be useful. For GD specifically, yes we can put in some mutexes as I earlier today put a copy of the GD library into PHP CVS so we can fiddle with it and distribute our own modified GD with PHP. -Rasmus On Sat, 13 Apr 2002, Brian Havard wrote: While doing some testing with Apache 2.0.35+PHP4.2.0RC3 I'm getting random crashes in T1_LoadFont(). Looking through the t1lib source (v1.3.1) I see frequent use of global variables which suggests it isn't thread safe. Is this a known problem? Maybe some mutexes in GD would help -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
