't Bijstere spoor

The last SabreDAV announcement I made here was 1.0.4, which happened in January. Just today I've released 1.0.9, so I figured it's time for a small update.

A public demo site

I've bought the sabredav.org domain, and placed a live demo on it for people to try out. Give it a shot:

• url demo.sabredav.org.

• username: testuser
• password: test

Please note that OS/X Finder will not be able to upload files here, because it uses the Chunked Transfer Encoding, which is not supported by sourceforge's webserver Nginx. Read more here.

Bugfixes

There's been a number of small(ish) bugfixes.

1. Fixed fatal error when a malformed url was called.
2. Issue 19: Better responses to HEAD requests on collections, improving compatibility with MS Office.
3. Issue 23: Fixed Allow header, improving compatibility with Evolution.
4. Issue 21: Typo.
5. Issue 27: Incorrect encoding of entities in properties.
6. Issue 29: Missing constant causing fatal error on lock requests with infinite timeouts.

So there it is. You can download the latest version on the googlecode project page.

CalDAV

CalDAV support is going well. Currently iCal, Evolution and Lightning/Sunbird are supported. If you want to test it out, be sure to download the alpha version (1.1.x), and read the related documentation.

IRC

I've also setup an irc channel on freenode.net. If you feel like idling somewhere new, head over to #sabredav.

Yesterday Mozilla Labs published the Contacts add-on, which I think is pretty neat. The add-on integrates your existing (Twitter, Gmail and AddressBook.app) contacts into your browser. It's pre-alpha stability, but it seems to work for me.

After installing it, it allows you to use contacts in two new ways:

1. Any <input type="email" /> field will now auto-complete with the contacts in your list.
2. A javascript api is added, allowing you (the developer) to pull in contacts from the user. The api is in the W3C standards track.

I love seeing these types of bite-size non-obtrusive features getting implemented in the browser.

The <input type="email" /> form element is specified in the HTML5 specification, but it mostly discusses validation & sanitation. It has been supported by Opera for a while, and Safari now does too. Any old browser will also gladly accept type="email", because the behaviour for unknown types has always been to revert to type="text".

So the next time you're asking your users for an email address, consider using type="email", which automatically makes you future compatible when all the browsers get around implementing it.

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..