Wednesday, May 23, 2007


It's been more than 3 months that I brought back to mind, what was happening in my PHP/HTTP/CURL world, so here we go.


pecl/http with support for persistent handles has been released.

A proposal of mine at internals to change the behaviour of read_property/write_property and get_property_ptr_ptr object handlers has successfully been ignored.

The idea was the following:

Wouldn't it be reasonable for the engine to use get_property_ptr_ptr() whenever it wants to modify a property and get rid of using read_property() for write access?

That would make rather simple ops like concatenation, in-/decrementation etc work again with overloaded internal classes. Just make the engine use read_property() followed by a write_property() when there's no get_property_ptr_ptr().

Nobody was interested.


I added a comparison object handler to the DateTime class, which means that comparisons of DateTime objects should work in recent PHP5 versions.

I started development of pecl/libetpan, but dropped it again because of pretty huge differences between how the library works and how PHP is supposed to work. What a pity.

A less fine guy, some Omid, wanted me to write a PHP extension which calculates the strength of "poker hands", but he jumped off when I had done the algos.


A fine guy, pretending his name was Andreas Weber, noticed that pecl/http's request method implementation was completely b0rked. Thanks to his report it was fixed in 1.5.3.

All fame Lukas Smith, queried me about what might have changed with my new output layer implementation for PHP6, but I noticed too late that it's been for a conference talk he was preparing, so I feel like I didn't spend enough attention to his questions. Sorry Lukas.

I started to implement libcurl's new multi_socket AKA hiper API in conjunction with libevent, but stumbled across a few problems.


My journey with libcurl's multi_socket API continues, which eventually causes the delay of a first pecl/http 1.6 release candidate.

I tried Drupal for the first time.

Well, that'd be it. If it reads like an extrusion of junk, it probably was. ;)

Wednesday, May 9, 2007

Phar vs World

Recent discussions about inclusion of pecl/phar into the core distribution shows again that we are missing a defined process of handling additions to the PHP main distibution. How many people are really reading through all mails of 100+ message threads?

It's going to be a chaos. Always. Once a developer has got his new, shiny and soon-to-be-world-dominating extension into the core, he'll be a even stronger advocator of the "no-new-extensions" camp. Not to disrespect any work, but this is pure rivalism, masculine--really!

The idea of moving extensions from core to pecl is honorous, but we all know the current problems of this ideology.

Many people have asked me when pecl/http will be included in the main distribution. My answer is short and simple: "Never" (I usually add a tiny sentence, but that's nothing encouraging either).

Ah... and please do me a favour: rather keep your comments to yourself :) (...or toss it into the nonsense thread@internals).

Thursday, May 3, 2007

Two pitfalls in one afternoon

This is not my day.

<quote url="">
words that are present in more than 50% of the rows are considered common and do not match

RTFM! ;)

Apache MultiViews are evil

Suppose you've got a similar setup to:

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule .* - [QSA,L]

RewriteRule ^network/?(w+)?$ network.php?path=$1

Apache will expand e.g. "network/foo/bar" to "network.php/foo/bar" which won't be expanded to "network.php?f=" because it --of course-- exists (RewriteCond -f).

Evil! :)