So as one of the last speakers, I finally got the opportunity to hold my talk on PHP6. You can find the pdf in my slides section as always. I was actually positively surprised that the room was fairly full, considering that I had seen several people head off to the airport already. I first asked how many people are still on PHP4 and a fair number raised their arms. Anyways, for some reason I felt that I was not speaking as fluent as I can, so I am a bit disappointed with my performance as a speaker. The slides however are probably the most complete resource for people who want to mentally prepare themselves for PHP6. One note of warning though: During my talk I noted that any of the changes/features listed can be reverted/dropped (remember how namespaces was dropped when PHP5 was already in beta) and some items are more likely to happen than others.

Anyways, the conference itself has been covered like crazy on planetmysql.org, so I will spare you all with just adding redundant content. However, I will list some random info tidbits I picked up during the conference:

• By 2008 you will have to think a lot harder about what storage engine to use with some adding very unique features
  • solidDB allows you to quickly switch between optimistic and pessimistic locking
  • nitroDB and scaleDB offering some unique approaches to indexing
  • falcon likely becoming the new default as of MySQL 6.0 (expected for Q2 2008)
    • Is MySQL AB the only company allowed to not postfix their commercially developed storage engines with "DB" (MyISAM, Federated, Archive etc.)?
    • On that note: I missed seeing a talk on the community developed (well of course the author is also working for a company ..) PBXT but I should also be mentioned here ..
• MySQL Optimizer has no way of getting statistics from storage engines unless there is an index
• MySQL 5.1 will add some rule based optimizer strategies for subqueries, but it will not be until MySQL 5.2 (not labeled 6.0) that subqueries are expected to perform well in most cases
• falcon will make everything variable length
  • on the topic of variable length, I heard conflicting comments on if it is worth putting in an effort to make your tables fixed length in MySQL
• Cache reads in the database and writes in your RAID and do not let any other layer cache things
  • A corollary to this is prefer more memory over a new shiny CPU
• If migrating to a new version of MySQL dump your data and reimport
  • Apparently otherwise some format optimizations will not be applied as was the case with innoDB when jumping from 4.1 to 5.0
• I am starting to think that using the Rails migrations approach (actually I think bugzilla used a similar approach before) is probably the best way to schema evolution, since it magically handles mixing of DML into your DDL as well as managing dependencies
  • However do not pretend like you can depend on downgrade scripts, since the reality is that its not going to get tested sufficiently
• Consider using two separate browsers for "public" web surfing and security relevant stuff in order to evade potential issues with cross site request forgeries.

A final note on Eben's keynote versus pretty much all the other keynotes. While Eben was arguing for leveraging open source to not hand all your personal data to others, most of the other keynote speakers kept plugging all these cool services that let you dump your data all over the web. Eben of course has an important point, we are all too willing to hand this information over. The danger is of course at some point "they" will know you better than you know yourself and I am sure you can easily imagine how that could lead to sneaky manipulation. However Eben did not mention that while the infrastructure is open source, there are still a lot of pieces missing that you would have to code in order to do your own YouTube or Pipes. Also Pipes illustrates the need for personal and (semi-)public database cross over, which means that some information nuggets might not be available to infer from. Instead the provider requires that you hand them the necessary data so that they can infer. Then again, like like DRM, you can choose to not participate.