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.

Perl EASC implementation

Besides XP4 and XP5, we're trying to get more languages to implement the EASC protocol. Yesterday, I committed a Perl implementation originally written by Marc to the XP SVN repository, testing and fixing bugs while doing so.

The experiment is available here:
http://experiments.xp-framework.net/?arena,easc-perl

Following the hype: AJAX, Prototype.js, JSON and the XP framework

With all the current hype on the (really not so new) possibilities JavaScript offers for rich client-side scripting, and people choosing frameworks because they are "AJAX-enabled", I'd like to show how to "WEB two dot oh" with the XP framework.

This article will show you how to create client/server interaction using JSON as wire-format, the Prototype JavaScript framework and the XP framework's JsonRpcRouter API.

Performance tests: Default arguments

Assume we have the following function:

<?php 
  function fixture($r1, $r2, $o1= array(1, 2), $o2= NULL, $o3= 'foo') {
    // ...
  }
?>

Code coverage

The XP framework's unittesting API has been experimentally extended by a userland code coverage implementation. For an example of a generated code coverage for the util.Binford class, have a look here.

Generics experiment

This is an experiment to show how rudimentary generics support could be embedded into the XP framework.

Generics in general
Think of generics as specifications of a type's component(s). For example, a List<string> is a list of strings, and a Map<string, Object> is a map of strings and Objects.

Further reading

• Generic C# Sample Programs
• Generics in Java
• C++ Templates Tutorial
• XP Blog: Apidoc: Generic types

Subscribe

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

Categories