"Ilia Alshanetsky" <i...@prohost.org> wrote in message news:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org... > Several reasons: > > 1) APC is well maintained, by the same people who work on PHP. > > 2) The license does not preclude it's inclusion into the base version. > > 3) most people don't use any opcode cashes, which is not ideal when it > comes to PHP. > > 4) apc inclusion does not prevent alternatives from existing... > > Ilia Alshanetsky > CIO/CSO > Centah Inc. >
Ilia, -the fact that APC is well maintained is not a strong argument because the other php opcode caches are well-maintained too. Well, better or worse, that's the question. Do you by any chance have any numbers to compare that would prove your argument? -the license is compatible? Well, let's move into php core everything that has a compatible license! So it is not an agurment either. (the opposite would be a strong arument because nothing with incompatible license could be added) -most people do not use caches? To me it's not exactly correct. Did you hear of XAMPP or WAMPP packages for Windows? Did you check the modules they distribute? How many opcode caches do they deliver? At least three AFAIK. That's Windows. About BSD - did you try to compile php from ports on BSD* alike systems? Didn't you notice APC among the options? As of Linux, APC is a module officially included with all major distributions. What would change for the end-user if you move APC into trunk? From these perspectives -- very little to nothing. -p.4 reminds me Microsoft's policy. The next step would be to create a trick in the API that will prevent the others from working, but APC :) It's my understanding <grin> that "people do not use opcode caches" not because they don't really use it, but because you are not aware of it :) People who are aware of opcode caches do really use them, not necessarily "the state of art and mainentance" APC. They mostly use eaccelerator and xcache, successors of Dmitry Stogov's turck mmcache. Who are not aware of opcode caches won't use them anyway until you FORCE them to use it. But you're not FORCING, right? If you move APC into php trunk, nothing will really change: only name of the module would lose its *pecl* part in the name and size of sources will increase and... Now a bit more serious moment: Since APC modifies behaviour of php core and it comes side-by-side with php core (from the trunk!), it's stability can't be left over. The release manager won't be able to release any further version of PHP without knowing for sure that APC is still compatible with the other changes and it works, and php works with cached opcodes, so the testers will have to run all tests at least twice, and do this under php SAPI that works with APC using shared memory, which is not the case if command-line php is used AFAIK. >From these perspectives, the benefits are not sensible, while negative impact is obvious. If you want people to be more aware of APC and use it more frequently, why not to add visiblity to APC, why not to write articles, show benefits in PHP conferences, etc. In other words, why not to go by a usual way? just my 2c -jv PS while some people are fighting for core of their projects to be as small as possible, php people are going by their own way: removing mysql extension that most people are using, and replacing it with APC that a very few would like to use... That's pity and funny. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
