't Bijstere spoor

I've been a big fan of Subversion since 2005, but since lately I've been having a bit of distributed source-control envy. Many people seem to be switching to Git and Mercurial, and frankly I've felt a bit left behind.

For some smaller stuff I've been starting to use Mercurial a bit more, and I've been pretty easily convinced since then. If you have some random code lying around, and need to make some changes you might need to revert? Just enter "hg init ." and now it's a repository. hg add, hg commit and it's committed as a first repository.

So I've bit the bullet and now also converted SabreDAV to Mercurial, which was a very easy process using Google's manual (which by the way could apply for non-google repo's too). The biggest change from here on is to remember to type hg instead of svn.

Joel Spolsky actually recently wrote a nice tutorial for hg, pretty easy to get through; especially if you already understand version control.

It's been a long time coming, but I finally have some working CalDAV code. The server has been tested with iCal 3.0 and 4.0 (Leopard and Snow leopard), Sunbird 1.0 pre-release and Evolution.

My main goal is to create a general-purpose CalDAV library, rather than a consumer-ready server app. I'm hoping people will be able to use this library to enable CalDAV functionality in their existing applications.

If you're interested in hacking around or testing, you'll have to grab a copy from subversion. Full installation instructions are available. Because of the alpha-stability nature of the code data-loss can occur, so beware!

The January issue of PHP|Architect just got published, and I'm in it!

I've written an apparent 5-page article about SabreDAV. The process was a lot of fun. It's definitely quite different from blogging, where quick and dirty is the rule rather than the exception. I hope I get the chance to do this again (all provided if there's another subject I feel knowledgeable enough in).

So if you get a hold of a copy, I would be very interested in your feedback! The magazine is in PDF form these days, so subscribing and downloading is quick and easy =).

According to a recent post from the Google Blog, Unicode nearing 50% uptake on the web. A rather steep graph as well:

This is pretty good news. I've had the 'pleasure' of working with a number of integration project where the 3rd party was still using iso-8859-1 (aka latin-1). Usually when this is the case, its not by choice but because of their software's default settings (Browsers, MySQL, etc.). I for one hope non-unicode charsets will soon be a thing of the past.

One other note in the post was about ligatures, such as fi and the dutch ij. If this is the first time you heard about these, you might be surprised to see that you can (likely) only copy-paste ij as a whole, and not just the i or j. It's one unicode character, not two. It just made me wonder: what kind of software would generate these, and more importantly why?

"A topic that has been beaten to death."

Standards advocates have been largely against the use of the <table> tag. The idea is that it's used for positioning and design, while it really should only be used for real tabular data. HTML should be a document with semantic data, and not contain any presentation information.

So the response is that all kinds of new techniques are devised to easily make stretchable designs. I just got handed a template that uses one of these techniques, along with a couple of others. Here's a snippet:

I can't say I blame the author of this code. He's always been told <table>'s are evil, and I have no doubts many 'experts' will suggest techniques like this.

There's no doubt this could be made much simpler even without using the <table>, but there's no way we can expect every junior frontend developer to memorize "1001 css hacks to make divs behave as a table".

The truth is, very little html documents are parsed by anything else but browsers and search engines. If an application's data is also consumed by other clients it will almost always be done through some kind of API or standard xml/json document. Even if html was used as a transport format, it will most likely be a specialized format.

Keeping HTML pure for data and CSS for presentation is a bit of a pipedream that never worked out. Even if you look at a relatively simple application such as Wordpress, every theme will have it's own HTML template, and not just a separate css stylesheet.

The point of my story is: HTML is read by browsers and developers. If you can make a brilliant HTML document and still keep pixel precision more power to you, but please keep things legible for the future developer that might need to fix a bug.

The upshot

CSS3 has support for multiple backgrounds, which will eliminate the need a lot of these problems. Safari has already supported this for a while, and Firefox will get it with the 3.6 release, and opera in 10.5. This leaves the browser that shall not be named.

I just released SabreDAV version 1.0.4.

SabreDAV now supports RFC 4709 through a plugin. This RFC defines a standard way to tell operating system a WebDAV share should be mounted. Example code to make this work easily is included in the actual RFC document (scroll down). It is not supported by default by any operation system at the moment, so if you want to plug your own DavMount implementation for OS/X or Linux, I'll be happy to list you.

The other change is that releases are now also pushed to Pearfarm. I'm still testing this so this might not end up being the official channel. If you'd like to try the new installation method, you can easily do so using:

Download here

For a while I've been pondering if it would be possible to build a free-for-all PEAR channel for everybody to submit their packages. I feel PHP classes kind of missed the boat here for requiring people to register to download, and well.. basically having a design that's just hard to take serious.

So since New Years, there are now 2! Yay for competition, but it's a bit sad they didn't choose to work together. I'm talking about pearfarm and pearhub.org.

Why PEAR packages?

If you publish your next opensource project as a PEAR package on a real PEAR channel, your users will be able to install PEAR packages by simply entering something like 'pear install packagename'. PEAR packages don't actually have to come from pear.php.net, but they can be hosted by any other server.

One of the benefits of getting your packages from pear.php.net, is that there is a high degree of quality control, as well as solid coding standards. I do believe though that there is a different part of the market of people who don't want to go through rigorous approval process and just want to get their stuff up for others to download. Inspired by Gemcutter; this is where pearfarm and pearhub come in.

As a bonus you'll get other fancy features PEAR provides, such as dependency management. You can easily make pear automatically download package A from author B if your package is downloaded.

What do they have in common?

Both pearfarm and pearhub are brand new, so very little packages are available. They also both seem to be a work in progress. Anybody can register for both sites and publish their packages.

Differences?

Pearfarm seems to be a more complete product, whereas Pearhub resembles the standard Pirum. Pearfarm also includes tools make it more easy to generate and upload your package and/or new releases. My biggest problem with Pearfarm is actually that it doesn't support OpenID. As a developer I'm surprised to see any code-related site being launched without OpenID support.

My pick today would be to host my packages on Pearfarm. The beauty of the PEAR system is that you don't have to choose one for downloading packages, because a package from Pearfarm can easily depend on a package from Pearhub.

Host your own

If you want to host your own pear channel, I can recommend Pirum. It's an extremely simple system that actually just generates static files. Chiara_PEAR_Server is a more complete system, but I've found it harder to customize.

I just stumbled upon an odd encoding issue with a web application.

Basically, data is coming into our PHP application through a Javascript's XMLHttpRequest (ajax). The data is sent as a standard form encoding (application/x-www-form-urlencoded), and picked up by PHP using the $_POST array. Any strings in form POST request are 'urlencoded', also known as Percent-encoding. As an example, this will turn a space into the often-seen %20.

Normally everything in the $_POST and $_GET arrays is already decoded, so when you're dealing with these arrays you don't really have to think about this. This time however, I was dealing with some non-latin unicode characters and for some reason they were never decoded and ended up in de database as raw url-encoded strings.

Doing a bit of research led me to the following: normally any special character is encoded as %XX, X and X being 2 hexadecimal values. These values simply represent bytes. The values I got were different altogether and took the form %uXXXX. I just assumed this was part of standard uri-encoding for unicode characters, so I was still a bit shook-up to see that PHP didn't just pick them up.

After a bit of research, I found out that the unicode representation was rejected by W3c, which is probably also why the PHP authors decided to not implement this. Javascript actually has 2 different methods to do percent-encoding, namely:

escape("☢"); // returns %u2622
encodeURI("☢"); // returns %E2%98%A2

Guess which one we were using?

Even though the %u syntax is arguably better to represent unicode characters, W3c seems to have voted against the syntax for backwards compatibility reasons. Before this happened the escape method was already adopted in javascript which in turn caused me to stumble upon this problem and write an article about it.

The more you know..

While OS/X's WebDAV implementation is quite slow, it is mostly pretty decent. The client uses the little used Chunked transfer encoding for PUT requests, which allows it to send big files without knowing exactly how big the file is going to be. A request like this looks like this:

While this is a perfectly legal HTTP request, webservers choke on it. Both Nginx and Lighttpd respond with HTTP 411 Length Required. This would have been valid for HTTP/1.0 servers, but if they claim to support HTTP/1.1 they must accept these requests.

Apache + mod_php does this fine, but just recently I got a report from someone using Apache + fastcgi + php. In this case the request body never arrived in PHP which can unfortunately result in silent data loss.

So I guess that's a bit of a warning, so far OS/X WebDAV only plays nicely with Apache + mod_php servers.

About a week ago, I moved to South Korea. While trying to share some video with the homebase (check my other blog). I wanted to upload some video's to youtube, only to be presented with the following message:

After binging it (or is it bang? I prefer bang) it turns out that any site with more than 100.000 users must require users to identify themselves with their real name and an 'identification number'. Youtube has instead blocked commenting and uploading altogether for South Koreans. I can't find much information on the subject other than some ZDnet articles.

I find this a bit scary. I personally enjoy my anonymity on the net.