I know that ZF strives to provide a balance between powerful tools and easy of use. However, reading this thread and others like it, it seems to me that there are two approaches "battling" here ;) The first one is the one concerning small to medium, shared hosting applications, while the other is for the considerably larger projects, projects with dedicated (or more sophisticated) hosting. In this thread clearly we can see the positions:
* shared-hosting ZF projects are expected to be harmed by "hardcoded" includes, because having all those exception files loaded is not necessary and seems like overhead; those are projects that run in environment with no opcode cache solution available (as more or at least some of the shared hosting providers). * ZF projects flexing opcode caching solutions are expected to me harmed by "conditional" includes, because they will not be picked up by the opcode caching. I think there are other areas in ZF like this as well. What I propose is to consider forking ZF into 2 "versions" - one that suites best the shared-hosting projects (small and medium projects) and one for the dedicated projects (large, enterprise projects). It is probably too early for a split like that, but at least it is worth discussing it: this seems like a very sane choice, because each "version" will be true to the purpose it is going to be used for. The API will be the same, just the implementation of certain parts will differ slightly to fit best the environment the library will be used in. What do you think ? ----- K. Regards, Kaloyan K. Tsvetkov http://kaloyan.info/blog/ http://kaloyan.info/blog/ -- View this message in context: http://www.nabble.com/Reducing-the-number-of-loaded-exception-files-tp14324215s16154p14566139.html Sent from the Zend Framework mailing list archive at Nabble.com.
