http://php.net/manual/en/security.magicquotes.php -- man, if only we wrapped string on a ini file setting, it wouldn't prevent injection attacks at all, really all it means is that the standard library isn't portable any more as the semantics and return values can change on a site basis.
http://php.net/manual/en/security.globals.php 'you know what would be good if we could trash variables from the browser' 'we've turned it off now, good thing that people won't turn it back on for older scripts, and it will affect every script'
www.trl.ibm.com/people/mich/pub/200901_popl2009phpsem.pdf - the implementation and semantics of php don't match up. it doesn't do what it says on the tin.
there are many php builtins which have vague return values which change indeterminately between releases and arguments, which forces you to use == over === for some comparisons unless you want your code to break unexpectedly.
the moral is: for everything they've fixed, they've often fixed by duct taping over the original errant feature. the standard library needs to be wrapped to be consistent. security or performance isn't a priority for the open source versions.
this won't bite most web applications as many of them are simple templates around a database.
with larger applications or frameworks, php struggles
tbh, php excels at being a templating engine. it is very easy to get data in and out of the database and into the browser.
however, the implementation of php itself is buggy and often plagued with security vulnerabilities. personally I just don't trust the platform, regardless of the language faults.
anyway
you should look at the components you have, and if php is the right tool for the job. if it is just templating, then whatever. but I would advise against long running services or daemons in php.
the maintenance burden may be availed by a better product. you already use postgres because it is easier than writing a database in php (obviously), so there might
be a few other tools or languages out there that can radically simplify your code base.
you might also find that node.js is good enough for new work, and using javascript instead won't create a significant burden since you already know most of it.
you shouldn't dismiss the possibility of refactoring or adopting new tools on the assumed maintenance cost without making a proper evaluation of it
it is too easy to fall into the cognitive trap of 'sunk cost' and continue on in the same way you've been doing things for 8 years.
Using the sqlite db as the canonical configuration is a nice idea, but reminds me of the fun of bind, editing one file to re-generate another. It is as if he is ignoring the advice in his older post about making software usable.
Instead of having a simple text format that is the configuration, he encourages everyone to write their own. I can imagine the fun now on a mailing list - debugging n+1 languages to start a webserver.
When you deploy, do you deploy the sqlite database file or the script that generates it? Does the daemon check if the db is out of date on startup? Does the script clear the existing db when it runs? Does it have merge logic? How do you keep them in sync?
'But it's powerful' I hear you cry, but my retort is simply 'it is effort to maintain, deploy and configure'. It smacks of: here is a bus port, go build yourself a keyboard. This sort of toolsmithery is what brings us delights like autoconf.
A simple change would improve things a lot, whilst maintaining the flexibility he craves:
instead of 'generate a config file' with your tool and hand it off to mongrel, the tool you write is part of mongrel.
You write a script called /etc/mongrel/makeconfig, that takes one argument, the name of the mongrel settings database. When mongrel starts, it invokes makeconfig to build the database.
You can provide a bunch of trivial makeconfig scripts as defaults, including a shell script that just runs a bunch of sqlite statements.
http://phpxmlrpc.sourceforge.net/#security early and naive implementations of xml parsers in php used eval, and as such were terribly insecure and hacked en masse
http://php.net/manual/en/security.magicquotes.php -- man, if only we wrapped string on a ini file setting, it wouldn't prevent injection attacks at all, really all it means is that the standard library isn't portable any more as the semantics and return values can change on a site basis.
http://php.net/manual/en/security.globals.php 'you know what would be good if we could trash variables from the browser' 'we've turned it off now, good thing that people won't turn it back on for older scripts, and it will affect every script'
http://php.net/manual/en/language.oop5.late-static-bindings.... - a dynamic language with an early bound oo implementation? sure we'll fix it, we'll just make the keyword for dynamic dispatch 'static'
http://php.net/manual/en/language.namespaces.php - the namespace character is the string escape character. I mean that will never backfire if people don't use 'variable functions', or using a string to lookup a function http://us.php.net/manual/en/functions.variable-functions.php lets hope we never have to put old code that uses this into a namespace.
http://php.net/manual/en/control-structures.goto.php man, should we implement a subset of goto or, should we do named breaks. nah goto is far more awesome.
http://use.perl.org/~Aristotle/journal/33448 - how do we fix a security vulnerability? why checking to see if an int is bigger than INT_MAX
www.trl.ibm.com/people/mich/pub/200901_popl2009phpsem.pdf - the implementation and semantics of php don't match up. it doesn't do what it says on the tin.
http://en.wikipedia.org/wiki/PHP_accelerator - php by default doesn't cache bytecode, unlike, nearly everything ever, for commercial reasons, as zend sell one as a product.
http://www.phpcompiler.org/doc/phc-0.2.0.3/representingphp.h... - the grammar is terribly broken, so much so it is nearly impossible to do obvious and useful things like foo(1,2,3)[0]
http://blog.php-security.org/archives/61-Retired-from-securi... the development team is toxic and reluctant to provide actual solutions for security
there are many php builtins which have vague return values which change indeterminately between releases and arguments, which forces you to use == over === for some comparisons unless you want your code to break unexpectedly.
the moral is: for everything they've fixed, they've often fixed by duct taping over the original errant feature. the standard library needs to be wrapped to be consistent. security or performance isn't a priority for the open source versions.
this won't bite most web applications as many of them are simple templates around a database.
with larger applications or frameworks, php struggles