Editorial

XP Release procedure

After introducing the new build system a while ago, we've produced quite a number of releases already. Time for some documentation, now that we know the procedure works as expected.

The XP Wiki now contains a step by step howto for creating releases and release candidates. Here it is!

1.0.0 - nine years later

Nine years ago we released XP Framework, version 1.0.0 with the following change log:

  . No more support for PHP smaller than 4.3.0
  . There is now a common subclass for Errors and Exceptions called Throwable
  . An exceptions stacktrace is an array of lang.StackTraceElement objects
  . Exception::getStackTrace() returns this array and no longer a string
  . Removes Object::getName() which has been deprecated for a while now
  . Uses xp::registry to keep the global namespace free of bullshit

TDS Protocol implementation

One of the XP Framework's strategies is to keep compatibility over a large number of PHP versions on multiple platforms. For example, the message digest API contains a workaround for certain PHP versions with a broken CRC32b implementation, hiding it transparently from the user. In other places like the lang.Process class, we take care of platform differences, employing OS and feature detection, and even compensating for some implementation vagaries. Constructs like this can be found in various other places in our code base, and while this is definitely not desirable, it at least saves the user from going through this hell, and this way, we support the full range of PHP 5.2.10 through 5.3.8 (inofficially 5.2.0 - 5.5.0-dev also works) on a variety of Windows and Un*x systems.

Following this strategy, we go as far as rewriting functionality previously available through a PHP extension to userland implementations: The FTP API (because of limitations in streaming support), the parse_url() function rewrite to work around behaviour changes, userland ini file parsing to support Unicode, a reimplemented MD5-crypt to compensate for a critical bug in crypt() in PHP 5.3.7 and our own MySQL protocol implementation to be able to support old MySQL 4.x instances, to name only a few cases.

The TDS protocol implementation supporting connectivity with Microsoft SQL Server and Sybase database servers is the most recent addition to this stack. Though not yet completely finished, we expect to be able to add it to one of the upcoming 5.8 releases.

apt-get meets the XP-Framework

The XP Framework has an easy-to-use installation mechanism - simply downloading a setup script and piping it directly to PHP. What this mechanism cannot do though is to install PHP as a dependency itself, which is usually done in an operating-system dependant manner. On Debian and Ubuntu distributions, the packaging mechanism is called APT (Advanced Packaging Tool), which installs Debian packages (.deb files). In order to build such a package, we need to create a control file as well as the intended directory structure and wrap all that up using the "dpkg" tool (there's a howto over at IBM's developerworks). Unfortunately, this approach requires the Debian packaging tools to be available for the build platform - a situation we cannot rely on. This article shows a solution written in the XP Framework.

Array and map types

PHP arrays are so comfortably usable for just about everything - mixing types inside, dynamically resizing them, mapping keys to values, this to that, and - using references - even can be used to create graphs. In addition, the PHP core library comes with more than 70 functions for manipulating them. This is great for rapid prototyping, as is the void-pointer in C.

The downsides of this approach is interop with most other programming languages, where arrays and maps are something conceptually different (Perl even has separate syntax for them, @ and %, and a mind-blowing implementation of the latter). For example, to know whether we're passing an int[] or a map of strings to object instances is going to make a big difference if we're, for instance, using EASC or SOAP to communicate with, say, Java or C#.

Show me the code

After reading and agreeing with Show me the code some time ago, I thought about how to integrate source code examples on the XP Framework website. While lots of blog postings here contain sourcecode, this is not prominent enough - so I set up a new site dedicated to this purpose: The XP Code galleries. Enjoy

SVN URLs

The XP Framework's checkouts you have on your disk should be originating from svn.xp-framework.net, and not from any other host name. While this may currently still work as all the other domains in use like xp-framework.de still point to the same server, we might want to change this in the future. To check what exactly you're using, type the following:

  ~/devel/xp/trunk $ svn info . | grep ^URL
  URL: svn+ssh://$USER@xpsrv.net/home/svn/xp/trunk

  ~/devel/xp/trunk $ svn switch --relocate \
    svn+ssh://$USER@xpsrv.net/home/svn/xp \
    svn+ssh://$USER@svn.xp-framework.net/home/svn/xp

Bind server sockets to any free port

At the company I work for, we let the XP Framework's unittest run on various different machines, including Windows 2008 server and 32- as well as 64-bit Debian Linux boxes, with PHP versions ranging from 5.2.0 - 5.3.1 (lots of permutation, yes).

Deprecation

Every now and then, we find out our decisions from the past weren't the most elegant ones, limit us in unnecessary ways, or don't fit into the bigger picture anymore. This is a natural thing, as we move on and gather experience, we see our solutions in a different light - and we see how a problem could have been solved in other ways. In reflective moments we start thinking "If I had to do this again today, ...". This happens in personal life but also - for programmers - with code we have written.

Unified runners in the web

The XP framework had offered developers the power of an easy class loading setup via the new XP runners that are delivered with every release since several releases now. These runners have proven themselves very useful in day-to-day business, so we're working on porting them to the web!

With the so-called web-runners these new cool and useful features will become available for you:

• Easier classpath setup
  Classpaths will be constructed from .pth files, in the same manner as xpcli does it.


• No boilerplate "index.php"s any more
  you won't need the same index.php over and over in every project again; even more: you don't need any entrypoint .php any more even for SOAP- or JSON-endpoints.


• Multiple etc/ configuration directories
  you can switch between multipe etc/, eg. one for the test server and one for production, by changing a single file


• Overwrite arbitrary settings for special servers
  you can overwrite settings, eg. debugging settings, based on where your application runs - eg. on the development machine, you can have debugging enabled, while on production it's disabled. You don't need to have different files for them - no more mistakenly committed debug settings.

Subscribe

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

Categories