Ok, I will try to get some coherent writing done for emPHPower this week. Whatever I will produce will probably end up on my wiki sonner or later. I am also in the process of setting up a mailing list (or should I high-jack the orphaned evangelism mailing list for this?). I hope this all will lead to a few people to step up and really start getting involved deeply in emPHPower. Aside from this Sebastian has handed in a BOF session on emPHPower for OSCON. I hope this one will work out. It does not seem to be in the confirmed listing yet though. Also Cal has notified me that they have reserved a spot for emPHPower at the unconference happening at ZendCon. Since I will not be able to make the trip over to California, I am hoping someone else will step up and moderate a discussion on emPHPower. If anyone could also use the opportunity to engage the more business-y crowd at ZendCon to get their POV, it would also really help out a lot.

So I have now joined Johannes as a co-RM for PHP 5.3. Its quite an honor and a challenge. Especially since I still need to find enough OSS time to continue to work on emPHPower and write out a proper proposal for a "constitution" (expect a mailinglist to be setup soon). We hope together we have enough brain cycles to push put what is probably the biggest minor release in the history of PHP. Just take a look at the todo list and the scratchpad detailing all the additions. Speaking of the scratchpad, we really really really need more people helping to identify the changes in PHP 5.3.

So I took my concerns over prepared statements to the #postgresql IRC channel on freenode. I pointed out that I think there should be a way to get server side handling of placeholders in statements but without the additional overhead of a second round trip or the drawbacks of overly generic query plans due to not being able to use the parameters in the planning stage. Some people have noted that this feature is available in MSSQL. It also seems to be available in PostgreSQL in the form of PQexecParams and its even exposed in ext/pgsql, though it's only used for sequence reading in PDO_PGSQL. It would be really cool if it could be used when emulating prepared statements (probably with a PostgreSQL PDO attribute).

So I took Roland's comment and tried to get it integrated into my code. For the tab management it worked well, but for portlet management it was a lot harder. Actually I only have a partial implementation finished. What's missing is the necessary logic to be able to move a portlet in the same tab from one column to another (there are 3 columns a portlet can be in for each tab). The thing that was most important to me was cleaning up the pruning operation. This took some trickery (aka hackery). I think its a better implementation but it does make me a bit nervous. Of course its all still very MySQL only.

The following is more or less just a thought stream dump from my train ride back from frisbee practice. I just wanted to jump start a discussion on how emPHPower should be organized. I think the general idea of establishing a communication hub for core developers, end users and companies has been received with sufficient enthusiasm to start working on some of the boring details. The next logical step seems to be to start to fleshing out how the organization behind this communication hub should be structured. I want to leave as much power as possible with the individual members, which is one of the main reasons why I do not want companies to be come members. When planning all of this I also need to differentiate the "bootstrapping process" and my vision for how things should be afterwards. Actually I will focus on the bootstrapping process, since I think for the most part the members should have the opportunity to decide on the structure later on.