Experiments

Userland database driver implementations

Following a discussion we had about software packaging for our test, qa and live clusters (most of which run Debian Lenny, meaning it brings PHP 5.2.6 with the mssql extension, unfortunately unsuitable for ASE 15 / univarchar fields), we decided two things:

1. We need to compile a more recent PHP version with sybase_ct ourselves
2. We should investigate in more independence from installed system libraries and PHP extensions

Extension methods: Swiss army knives without the anti-pattern

The following calls a method called "sorted" on an instance of the lang.types.ArrayList class. The ArrayList class doesn't have such a method, and we'll thus get a nice "call to undefined method" error shortly before our program is terminated.

<?php 
  $array= new ArrayList(3, 1, 2);
  $sorted= $array->sorted();
?>

GUI API redesign

The XP Framework's GUI apis date back to the PHP4 / GTK1 days and have not been touched since then. In desparate need of an overhaul, and following the PHP-GTK2 releases and the stability provided by its PHP5 backing, I began an experiment to redesign the API from scratch.

Watch the experiments' arena/gnome directory for more!

XP Runners in C#

The XP runner infrastructure (as described in RFC #0166) provides a flexible way to run the XP framework without having to configure PHP's system-wide include_path. Besides the already existing implementation in /bin/sh, there's now an implementation in C# (using the .NET framework 3.5). Apart from being a training project for my C# skills, it's also five times faster than using shell scripts on Windows via Cygwin:

http://experiments.xp-forge.net/xml/browse?arena,xprt,csharp

PHP 5.3 Experiments

All the experiments with the newest PHP version can be found at the XP Forge's 5.3 experiments.

Compiling the XP framework

Lately I was experimenting with the PHP extension bcompiler, which offers an API to write the opcodes generated from zend_compile() to files. For a general understanding of this you must know that PHP is a compiled language (but does compilation into memory and then executes that instead of compiling to disk and then running that). The compilation step is not exposed to the user in any way, and there is no defined serialization format for compiled PHP. This is where bcompiler comes in.

Note: Compiling PHP sourcecode does not improve runtime performance, it simply saves the (small) overhead generated by the compile step. My main focus in this experiment was not performance, though, but to test the ability to generate PHP bytecode, and if that would work transparently alongside PHP sourcecode.

HttpService

There's already been a couple of people out there implementing a web server in userland PHP. From my point of view, people are doing this for fun, or as proof-of-concept, and those experiments usually tend to fade out of sight and disappear from public interest - so my guess is that they're not seriously being used.

At 1&1, we actually have such software running in PHP - multiple instances of FTP daemons which serve the purpose of attaching functionality to uploaded files (when an image is uploaded in this directory, update the underlying database), an application server called "Peking" that stores when a customer care agent has opened a customer's contract, and a real-time-logger that stores extracts of Windows Media Server logfiles transmitted via network into a MySQL database for billing reasons. All of these process thousands of requests every day and handle database and LDAP failures gracefully, and all of them have stable memory usage.

As a word for all disbelievers, daemons in PHP are possible!

To demonstrate how this works with the XP framework, I've written a web server implementation using the peer.server package.

Performance experiment: if / else vs. switch / case

Starting from the following piece of code which is basically an excerpt from the remote.protocol.Serializer class:

<?php 
  switch (gettype($arg)) {
    case 'integer': $r= 'INTEGER'; break;
    case 'string': $r= 'STRING'; break;
    case 'boolean': $r= 'BOOL'; break;
    case $arg instanceof Object: $r= 'OBJECT'; break;
  }
?>

Different XP framework classloading implementations compared

Classloading is a very interesting topic. Classloading is a very fundamental and - at the same time - invisible thing, that nevertheless happens a million times each second (if you aggregate all instances of applications that run the XP framework).
Because it happens so often, one must take special care when modifying the framework's loading implementation. A single line more here or there can impact the framework severely.

If you then take into account that for bootstrap classloading not a single one of all the convenience providing classes from the framework is at your command and everything needs to be a) fast, b) flexible and c) working at all, you might see that this it can be quite difficult to come up with new implementations here.

The whole world in a xar (or: Running the framework out of a ~)

This weekend, I've started extending .xar handling in the XP framework's core to support starting an application out of a xar.

Basically, this should have some benefits for applications: they need to only provide one file that can be invoked with a PHP interpreter out of the box. Think of how cool a one-file-GTK-application could be (even though this method could also be used from web applications).

The experiment's purpose was to show a) that this is possible and b) what would be needed to be changed in the framework.

The experiment can be seen at http://experiments.xp-framework.net/?people,kiesel,php,selfrunning.

Subscribe

You can subscribe to the XP framework's news by using RSS syndication.

Categories