Having a great time down here in Brazil. So far a lot of relaxing at the beach. Next week the world championships will start. So I spend a bit of time practicing throwing and catching in the wind. And of course I also gave a talk at the PHP conference in Brazil. Very impressive conference. Quite huge, well equipped. My talk was shown in 3 other rooms because they did not have a room to fit the 500+ audience in one room. There was a guy translating my talk to brazilian. Its quite nice to just say a few sentences and then have time to think about the next sentences as you watch the reactions in the crowd. Anyways, the slides have been up on my server since a while already, but no link. So I have added the talk to the slides section.

I have complained about this IP protection blabla put forth by CLA protected projects previously. But I keep hearing the same (imho false) arguments that CLA's are a non issue. I was kind of shocked that neither the Zend nor the eZ Systems representative at the PHP Conference in Frankfurt was able to display that he actually knows what is in their respective CLAs. One issue is the one-way OSS, where due to the explicit copyright grant required, it becomes hard to cherry pick OSS code. While thats annoying, the bigger issue imho is the problem of the patent grant clause found in all CLA's I have seen (which all seem to be derived from the apache CLA). I keep bringing up this point until people who push CLA's will finally stop repeating lies about them. Saying that single developers do not need to worry about getting sued over patent infringements is simply wrong.

Thanks to the support of Hannes, the first couple of readme's are now reST'ed over on php.net. Actually this also includes a new readme which is essentially a port of the release process wiki page. Anyways to get things to work I had to modify my initial script a bit. After a chat with Hannes we figured out how the script should work. Essentially we have one script that does the rendering based on a list of files that is hardcoded, which results in some happy HTML'ed files. These then get served up by yet another script with all the nice navigation stuff, including user notes around them. Hannes took care of all of that. Simple enough. Anyone who wants to help out feel free to just port a readme to reST (note that our reST parser has some limitations atm, so better look at the current ported files for inspiration).

Avid readers of my blog know that I have been pondering how to best approach schema evolution. I ported the schema management from Metabase to PEAR::MDB2_Schema. I even gave a talk that admittedly only did a good job of defining the problem and solutions that all suffered from severe limitations. Now for the first time I am starting to feel somewhat good about an approach to migrations. I wrote a post to the Doctrine developers mailinglist detailing the key pieces that I want to add to Doctrine's migrations. The idea is to use the migrations approach made popular by Ruby on Rails but improve this concept with several key additions.

We have taken over an application which had "pretend" failover. Essentially it had two servers with automatic failover between the two. However they both relied on another server for providing the data storage via NFS all the way down to the MySQL server. Interesting how one can manage to provide no real failover with 3 servers. Obviously we want to fix this and actually a number of servers have already been bought. So now we have moved the MySQL server with a cold standby on separate machines. We also have 3 frontend servers which we want to load balance. We will probably use memcache to manage the sessions, as we are not so worried about a lost session when a crash occurs. But now comes the problem: There are a lot of places where administrators and end users can upload files, which end up in the file system. Now how do we replicate those files across all the nodes?