Re: Some more plane hacking...

Nicolas Hoizey wrote: > > > Please don't cut the other reasons :-) > > I just wanted to comment one of them, so I found logical to keep only > this one ... The others are in the archives. :) Trying to solve one thing you won't solve all things :) > >> Speed is often a real issue for professional use of PHP, so having > >> some of the core components of PEAR available as extensions would be > >> great ! > > > Let's define "professional". I have one server with 1,5 millon > > _hits_ a day with php, templates, postgres, and it's running fast > > and smooth. > > Great, but what is the mean time of each request ? Visitors don't notice any delay, so fast enough (even taking in mind that the server is a humble box: Duron 600, 256ram, ide discs). > Do you use any caching tool ? Nop :) The first purpose for the site was sightly different from the final purpose. But the owners don't want to spend money on this yet, because the site is running without problems (I mean the costs of maintaining 100Gb/month data transfers is enough for them). > I think Zend Cache would increase a lot PEAR based developments > performances, but I have never tested it. "Professional" leads to > "profit", and I think those who have money should use Zend Cache. Sure, but for most develpments having more hardware or use "unexpensive" cache tools like Smarty or APC (http://apc.communityconnect.com/) will be enough. These are my reasons why I'm against to sacrifice usability in the place of some speed. > > The amount of speed you can gain optimizing classes is nothing > > compared to optimizing queries, databse, SO, web server. > > I agree, but IMHO, having database abstraction and error handling in > the core of PHP would be a really good thing. Not only for > performances, but also for ease of use. PEAR means things out-side the PHP core. I'll be glad to see the error handling stuff inside PHP, but that's other thing out of PEAR space. From my egoist point of view, I use PEAR::DB because I can easily modify it, if I couldn't I simply won't use it or would start my private fork. That's only my personal situation, I guess that many of you will be happy with it. Also note that there is yet a database abstraction layer written in C (/php4/ext/dbx). > >> I think it could be possible to have both the C and the PHP versions > >> running together, the right choice being made "automagicaly", don't > >> you think ? :) > > > > If so, yeah no problem and no more discuss :-). > > Great. > > > But I (and I'm sure many others) don't want to spend > 4 hours > > propagating changes of a C extension thru servers with differents > > operating systems/c libs, when I can do it in two minutes with > > .php's. > > I also prefer php over C (maybe because I fear compilation stage) but > we are talking about stable classes which are rewriten in C, so their > API should not change, and there is no compatibility issue here ... I was talking from the sys-admin point of view. In the last phplib security advice I spent 15 mins to upgrade phplib in 4 servers. With an imaginary C phplib I'd spend all the afternoon. > > Just ask a question if you let me: the guys who are promoting C > > extension will join to pear and work in the this C extensions? will > > maintain them? will ensure cross-platform/cross-compiler ability? > > will attend bug reports? > > As for other extensions, the maintainers are responsible of all that, > and each extension/class/package has it's own "vitality" which tells > us if it's reliable. Please tell what is the vitality of the Stig's PEAR base class in C. > I apologize if my speach is not clear, but it is a simple mirror of > my boiling brain ... :) Never mind I apologize also for my limited enghlichz :-) Please don't get angree with me, I know here is plenty of C-men-php-gurus. I'm talking from the "php user/developer" point of view that guess it's being forgot. Tomas V.V.Cox