Hi
 
 With our current PHP5 integration, some of the extensions has been 
built into the PHP core rather than as shared object (<extension.so>) . 
For example, as of Nevada build 76, these are the extensions that can be 
compiled as shared object but has not been as of today.

bcmath, calendar, ctype, dom, exif, ftp, hash, iconv, json, mbstring, 
pcntl, shmop, soap, sockets, sysvmsg, sysvsem, svsshm, tokenizer, 
xmlreader, xmlwriter,   

 Compiling these extensions as 'shared objects' has the following advantages

1) reduces the memory footprint of the php binary and the apache / php 
module.

2) PHP needs to be compiled multiple times to support multiple SAPI that 
are we are delivering. For example, CLI, Apache2 module and CGI/FastCGI. 
Now, if all these modules are compiled as 'shared objects' then these 
objects need not be compiled multiple times and can still be used by 
these different SAPI.

and the following disadvantage

1) these extensions will need to be manually enabled within the PHP ini 
file before using it.

Going forward, I would like to see that we update our php5 build process 
to release these extension as shared objects rather than bundling in. 

If community does not see any see issue with this, then we can capture 
this change as part of the new ARC case that we are planning to 
introduce to include support for additional extensions that are coming 
in the next phase of PHP integration.

Any comments ?

thanks
sriram

Reply via email to