in PHP source:
./configure --help
I've had a look and it would appear that all that switch does is install
PEAR for you during the build process. That doesn't change the fact that
it's still just a collection of PHP classes and does not require
rebuilding of PHP to benefit from it.
sure no problem, again mostly I was speaking in gernalities about how
its works and referencing the switch since you'd never heard of ti.
You're also making it sound like adding ZO to a PHP installation is a
mammoth task... it's not. It's just as simple as building PHP itself.
Which is a mammoth task ;)
How so? Take any other interpreted language, and you don't usually get
Even though PECL and PEAR alleviate some of the headache by trying to be
CPAN, much funtionality is based on build options (mysql, curl, etc)
So if I find that my server does not have, say, mysql support built in
or I need a special kind (see ./configure --help for a list) then PHP
will most likely need recompiled.
If it breaks, you may break PHP for everyone, it may even take down
apache if the .so got goofy.
With Perl
perl -MCPAN -e 'install DBD::mysql;'
if it breaks then
- all scripts still work
- apache still works
pre-compilation for free. Correct me if I'm wrong but this goes for Perl
as much as it does for PHP. You have to 'jump through hoops' to get it.
one command, no possiblity of breaking anything, one hoop, very low to
the ground and about ten feet tall :)
Out of curiosity, why do you find it easier to manage Perl on 13,000
servers? What specific advantages does it have over PHP when it comes to
this?
Perl just works and make sense so its easier to code with. Any issue
sthat do come up now and then are usually resolved by a moduel upgrade,
one CPAN cpmmand :)
So any user on your systems can recompile apache or PHP at will?
Yeah, I don't stop them - more hassle than it's worth. But they'll be
Ok, i guess I'm refering to running a webserver that all the user's
share. If "bob" needs --with-curl then PHP needs to be recompiled. in
practice most hosting customers are hosting customers because they
woudln't knwo anythgin about compiling their own anything.
Its all really besides the point though, perhaps I shoudl have just
phrased it "you have to recompile some major stuff just to add minor
functionality"
My personal experiences with PHP and many other internet technologies
is quite extensive.
I don't doubt that, but I'm not understanding what Perl gives you that
makes it easier to manage than PHP. Please explain it to me so I can
As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
PHP" rant :)
learn something from this exchange. You clearly feel quite passionate
about it, so please share.
Actually since most everyone has expressed an interest in stopping this
thread, I think I will. Teh facts are there do as you wish :)
A solution is a solution, PHP is just one tiny option, I was offering
an easier to work with alternative.
Without adequately explaining why it's easier. And more to the point you
Sure I did, no one wants to hear it though :)
are still on a PHP list, and as I've stated before, the question was
clearly asking for a PHP solution.
True enough, but if you want to be strict then why not send them to a
none DB list?
Feel free to ignore the rest of this post, which I hope you'll take
in the spirit it is meant, but please answer me this. What has PHP
done to you? Why are you so anti-PHP? And specifically why are you on
a PHP list suggesting people use a different technology?
PHP has all the problems I've been specifying, that costs time and
money, and I'm sick of it :)
Yeah, I got that already :). What I haven't grok'd is what specifically
makes Perl easier and therefore cheaper to manage.
As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
PHP" rant :)
Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what
makes PHP the last choice for any project.
Again, this is a statement that makes no sense to me. You've made a
statement saying you hate something without explaining why. Do you see
Because its got *soooo* many problems, security, development, admin wise
- details throughout this thread :)
why it's very hard to learn from you when you don't justify your hatred?
What's the problem with the MySQL modules available for PHP? I
Those configure flags have so many combinations to get unpredicatabel
behavior this is the pseudo thought process while doing it:
--with-mysql (make sense so far)
but lest add the super duper mysqli stuff:
Oi crap what arg do you give it depending on what --with-mysql 's value is?
--with-mysql=/usr --with-mysqli=path_to_mysql_config
--with-mysql --with-mysqli=/usr
Is all of that mess the same on PHP 4 and 5 ?
What if you have mysql 4.0, 4.1, or 5 ?
and once you get your head wrapped around it are all the badly named
funitons gogin to behave the same?
personally have never had a problem with them, but if there is a better
way I'm all ears.
yep, use Perl's DBI modules or some other API (C, Python, Ruby,
*anything*) to MySQL that is consistently easier to setup and use
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
