CGI and FastCGI aren't the same. CGI is indeed very slow. FastCGI is pretty good.

I vaguely remember seeing some benchmarks that claimed Nginx+FastCGI/PHP has roughly the same performance as Apache+mod_php.

It sounds like you're just getting the benefit of having a set of libraries that you like and know well. There's certainly nothing wrong with that. I might look at the Zend stuff again if I end up doing any more large PHP projects.

Maybe the problem here is the definition of "framework". In my mind the whole point of a framework is to impose itself on the programmer. Typically along the lines of:

• there shall be three tiers to your application;
• we'll call them model, view, and controller even if your app just provides an API and doesn't require a "view";
• we'll make using stored procedures really difficult;
• we'll wrap SQL with an ORM that's less powerful, slower, takes just as long to learn, and isn't used anywhere else in the industry;
• we'll replace mod_rewrite with our own request router that's less powerful, slower, takes just as long to learn, and isn't used anywhere else in the industry;

I feel the frustration level rising just remembering all this. But it sounds like you get my point quite well and, like I said, I'll take a second look at Zend based on your comments - thanks.

This has gone off-topic, but... the various caching solutions don't always work. Since PHP discards all of its data with each request, complex data-structures that are slow to assemble but fast to access aren't possible. In this case I've suggested C or Java (or even Python) because the data can be loaded into RAM and pumped out at a high rate by traversing some carefully constructed data structures. Something like memcache can help a bit, but traversing the a large linked data structure still ends up being slow. Memcache helps when you can look up your result using a single key - it doesn't do much to speed up complex multi-index queries.

This is obviously an edge case - SQL stored procedures or one of the caching solutions will do the trick for most applications - but really this job would be far easier with a different choice of tools. This complaint is only tangentially related to frameworks, though. The frameworks aren't the problem here, but more the one-size-fits-all attitude that seems to come with them.

The patterns are really the crux of the problem. Design patterns are an excellent tool, but applying the same design pattern to every problem doesn't make sense. They need to be selected to match the problem. That's where the frameworks go wrong. At least the ones I've seen attempt to wedge everything an MVC pattern on the server side, which really leads to a lot of confusion (and enough misunderstanding of what MVC means that the term no longer means anything).

If you can really use the Zend libraries without pulling in all the other cruft than that's great. Choose them if they suit the task. Then you're really just doing what I suggested to begin with - selecting the best libraries for the job. (My impression was that this wasn't possible, but I didn't dig very deeply into Zend - by the time I looked at it I'd already developed a deep hatred of frameworks.)

Apache is generic knowledge in that you can apply it to a wider range of problems, and since every installation needs a web server, it's not something "extra". You have the tool already - learn to use it. Same with Nginx or one of the SQL servers. Every component you add has a cost in maintenance and complexity, so don't add more components until you've fully exploited the existing ones.

My main complaint with frameworks isn't efficiency. But you have touched on another problem. I know one poor sucker whose life is now devoted to trying to optimize an all-php solution, when a few weeks of investment in a Jave or C component would speed up his application 100-fold. Alas, try convincing a project manager that you need to invest a few weeks optimizing without producing any new features. He'll be stuck tuning that app and trying to squeeze performance out of Memcache until he burns out.

As long as your application domain is very close to what the framework was built for, yes. That's why I made the exception for slapping together quick, form-based, database apps.

For other cases, you're trying to make a design that works well for one case fit another. Better to invest the time learning to apply more general tools that you can adapt to your problem.

... unless you're in the business of throwing together form-based database apps quickly.

That's really all they do well, and there area lot of form-based database applications in the real world, so that's not a small niche.

But for anything that's a little different, you end up spending a lot of time learning the framework, and then even more time working around its limitations. The better approach is to look at your problem and find a set of libraries that are well suited to the task at hand, well documented, well supported, and modular.

Also, take the time to learn your tools properly and exploit them to the fullest. Learning a framework takes time. So does learning about Apache modules and SQL stored procedures. The difference is that the time invested in the framework isn't generally applicable to other problem domains, while Apache and SQL are everywhere, and are worth learning well.

The global menu is the problem for a significant number of people.

I could learn to live with just about every other Unity change, but the global menu drives me bonkers. When my visual focus is on an app window on my second display, I expect to be able to go to that window in order to work with the app. I don't expect to have to click on the window first, then move my mouse to the other display in order to access a menu that (oddly ) isn't located anywhere near my application window.

I've never understood why Apple sticks with this setup. It made sense with the original Mac, which had a tiny screen and didn't really support multi-tasking. It's a huge usability problem for modern desktops with multiple, large displays.

This is the crux of the issue. My understanding (and I guess also Google's understanding) of copyright law is that the copyright is only for the "creative" element of the work, and explicitly excludes things required for interoperability.

So if you take out all the comments, organize the remaining header in a completely non-creative way (ie. sorted by subject area, and then alphabetically), and remove any lingering "private" parts that aren't strictly part of the API, what remains should not be subject to copyright.

It may be true that this has never been tested in court, so I don't know were I got the idea that this is how things worked, but if I'm wrong then I've been under this delusion for at least ten years or so.

I'm sorry you don't trust your government, but it's just a fact that they're the only organization that can verify your identity. A private third party (like Verisign or some hypothetical non-profit) will rely on government ID to establish your identity as well. Given that these private groups don't add any real value, it's silly to pay them money for something the government can do more efficiently.

If you don't trust your government to perform this service, then you've got bigger problems. If the government wants to impersonate you, they can make some fake ID, get credit cards, SSL certificates, etc. in your name, and even arrange it so that your real identity looks like the fake one.

And to be honest, I think even in the U.S., your government is more trustworthy than the likes of Verisign.

These are oganizations that we already deal with and are in the business of establishing our identities and securing transactions.

When you're paying money on-line, you (or your browser) should sign the payment authorization using your own bank account's private key (provided for free with your account) and the encrypted with the public key for the destination account. The recipient will submit the signed authorization to his bank for payment.

For SSL protection of your web site, the government should issue SSL certificates as a free option whenever they are confirming your identity anyway. For people the obvious touch-points are when you get a social security card, driver's license, passport, or birth certificate. For companies, the certificate should be part of your company registration.