> > "Ilia Alshanetsky" <i...@prohost.org> wrote in message > news:aanlktilzlbbfucuv-jtmkm-qljl1il7wsqy0fyhn3...@mail.gmail.com... > Including into core of PHP has no impact on other opcode caches, if > they do a better job then APC, people can definitely (and should) use > them. The main purpose of including APC would be to raise the level of > awareness PHP users to the fact opcode caches exist and should be used > in virtually all instances where PHP is used. > > Most people do not use opcode, I know it from asking that question at > just about every conference. As if you do a google query searching for > phpinfo() and try to find those with any cache, you'll see that there > are FAR fewer of those then those without any caching being enabled. > > Just because APC package exists on most linux and BSD distros does not > mean people know what it is, you have lots of extensions that are > available as packages... > > How is adding an extension forcing anyone to use, dba extension has > been in core in ages, and only people who choose to use it do... "in > core" does not mean that you must use it.
Obviously, the target should not and could not be to just improve the awareness of opcode caches. If you want to improve the awareness, there are many ways that would leave all competing caches under the same equal conditions. For example, add a table on pecl.php.net: ten most popular pecl extensions and duplicate it on php.net. As soon as APC appeared there, it will be seen and all people will be aware. If people behind XCache or eAccelerator decide to move in this direction, they would make the license compatible and bring their code into pecl. Isn't it a right way amongst many other right ways? How would a disabled and potentially even not installed php extension affect awareness? In fact, you can add APC into trunk and you can remove it, nothing will change on a particular platform until the OS vendor (like RedHat) will move or remove the module into/from php package, and what they will do is not that obvious. Try to talk to them first: are they ready for the change? Adding APC into trunk makes it preferrable while the choise is based on the fact that one of the people behind APC is the php creator. After all, I'd love to see Zend's people opinion posted on this thread. In particular Zeev's and/or Andi's. Dmitry should be listened too. You didn't answer to the question about problems with further php mainentability. How the releases process of PHP will be changed? What will be done in order to keep APC as bug-free as PHP CORE which functionality APC affects. -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
