Het Bijstere Spoor

Over the last month I've been working hard at the Atmail office in sunny Australia to get CardDAV support built into SabreDAV; and I've finally completed all the steps to do this release.

So there it is, CardDAV. Unfortunately there are not yet a lot of clients who actually use it, and it mainly comes down to iOS and OS/X, but I've been asked about CardDAV a lot and suspect more people will become interested in this protocol (especially if more vendors start supporting it).

So that's pretty much it; head over to download page to fetch a copy. I've had to break a couple of minor api's, you can read about those in the migration document.

• Full changelog
• Migration document for 1.4.x users
• CardDAV documentation

I tried my best to write good documentation for the new stuff, but it's always very time consuming, and not as good as I'd like If you have time and the will to write more, let me know!

Lastly, a big thank you to Nick Boutelier for creating the new SabreDAV logo!

Well, I just checked my calendar and it turns out I've been blogging for exactly 5 years now. This is the only time I allow myself to make an off-topic post, so here goes:

An exciting year indeed, with lots of change. Moved back from Korea to the Netherlands, started a new job, spoke at a conference, and I've met lots of bright and interesting people.

I've been royally sucking at blogging though. Only 22 posts in the entire year. Worst year to date :) I really should get back into the game, but I steadily feel that the things I'm running into from day to day becomes less relevant to blog about, as there has usually been someone else with a much better description of what I'm really trying to say.

Maybe that's just an excuse though.. If you're still reading, thanks for sticking with me!

Although PHP's loose comparison type juggling tends to invoke some negative responses, I don't think it has really ever worked against me, and works quite comfortably in my opinion. As long as you make sure you always use strict checking (=== and !==) where you can, and fall back to the loose checks when you must.

As a PHP developer, I think it's very important to understand and memorize exactly how these work, whether you're writing new code, or maintaining existing code.

A few days ago on PHP-internals I saw a behavior that was completely new to me, and very much counter-intuitive.

if( '20110204024217300000' == '20110204024217300264' )
  echo 'equal';
else
  echo 'not equal';

Guess what the output is.

PHP will for loose comparisons always try to convert numeric strings, even when both sides of the comparisons are strings. Because the numbers are too big to fit in an integer, they are converted to floats. For both numbers this conversion ends up in the number: "2.0110204024217E+19" (give or take, based on the standard precision settings).

In my mind it makes sense to do this type juggling when a comparison is done with <, >, <= or >=, but it definitely feels like a bug when doing an equals check.

The moral is: always do strict checks when you are able to.

Thanks to Matt Palmear for pointing this out.

We're all being drilled over and over again to always use mysqli::escape_string, PDO::quote, or preferably prepared statements when escaping user-supplied strings for use in MySQL queries.

The downside to these methods is that they only work when there's an open connection to a server. So what if there's no connection available? In traditional Unix philosophy I'm writing an export script that doesn't execute SQL statements right to a server, but sends them to stdout. Forcing people to make a connection seems like a major inconvenience.

So what's left? Manual escaping I suppose.. The manual page for mysqli::escape_string mentions: Characters encoded are NUL (ASCII 0), \n, \r, \, ', ", and Control-Z..

function dontHateMe($unescaped) {
  $replacements = array(
     "\x00"=>'\x00',
     "\n"=>'\n',
     "\r"=>'\r',
     "\\"=>'\\\\',
     "'"=>"\'",
     '"'=>'\"',
     "\x1a"=>'\x1a'
  );
  return strtr($unescaped,$replacements);
}

There's a risk though.. Certain multi-byte character sets (such as BIG5 and GBK) may still allow for a security hole. You *should* be fine with UTF-8, so make sure you start your file with:

SET CHARACTER SET utf8;

Still no guarantee from my side though. Tread carefully and avoid this if you can. If you have a better idea, or you feel like shouting at me for this.. let's hear it in the comments.

Special thanks to Spudley for providing me with a reasonable answer to this question.

I'm officially stopping development for my SabreAMF and Dropbox php library. I'm using neither myself anymore, which is detrimental for my interest and time I devote. So I felt like it's better to make it official.

I'm hoping for both projects they get forked and picked up by other people. I'm happy to transfer control of the sites to a different developer, if he or she can show good coding skills and some dedication. Dropbox-php has a mercurial repository so it's easy to clone / fork, and I just migrated SabreAMF from svn to git(hub).

Dropbox

Dropbox was a short ride. When the API first came out I had some projects in mind I wanted to write for it. Since there wasn't a PHP library yet, I took it upon myself to write one. My interests quickly moved to different subjects though. Bugs are there, and left unrepaired for too long. If you know of a good replacement library, post it in the comments.

SabreAMF

While the Dropbox lib is from pretty recent, SabreAMF is from somewhere early 2006. It was my first open source project, and it has been quite a ride. It's interesting to think back to where I was in life back then.

It kind of went downhill when Zend_AMF got released in late 2008. Originally I was helping the (paid) developer with the implementation, but then communication went silent. I only heard about it again when it was announced with much fanfare as the Adobe/Zend partnership.

This left me with a bit of a sour taste. The developer at the time was struggling with decoding the AMF0/3 bits, which was just released as an open spec at the time. Originally the AMF0/3 specification was closed, and as far as I know, there were no open source implementations. It took me several months of reverse engineering to figure it out exactly. This was probably also largely due to the fact that I had little experience in this field and never seen a variable width binary-encoded 29-bit integer before. So I was mostly doing it blindly (with help from the excellent Karl Von Randow and Kevin Langdon). Having a working implementation after that time felt like a great achievement.

After checking out Zend_AMF, I found that the developer didn't bother trying decoding himself, but effectively just took my design and renamed a few methods. Mind you, these were only a couple of classes, but they were the core of the project and my blood sweat and tears. I wouldn't have minded this if I could have been a part of it (which I thought I did for a bit), but it wasn't handled very decently. Since then the Zend_AMF library has greately improved, so the evidence is stowed away in much older subversion revisions.

I hope this doesn't come across bitter. I mean no harm to said developer, his perspective may well be very different from mine. I just wanted to write this out as therapy, as this has been bugging me personally for several years.

However,

I had tons of fun and learned even more. Very much a thanks to the users, and the people that helped me out in various occasions. I still believe there's room for a 'SabreAMF', as the main message I've always heard from people was that the alternatives are too heavy.

I've since then moved away from flash-work as much as possible, with the exception of the occasional feature that flash provides well, but browsers don't yet (video). If you're thinking you need an 'AMF'-like solution, I would first highly recommend to see if JSON does not already fit your needs. There are some benefits to the binary protocol, but they only tend to apply with large scale. Most people don't fit in that category. If you do, check out Zend_AMF.

I'll be speaking the next PHPBenelux meetup in Amersfoort about implementing WebDAV using PHP. Joshua Thijssen will also be doing a talk about MySQL optimization. The meetups are free, so if you have some time after work, drop by and say hi. You can sign up at the PHPBenelux site.

In case you're still using w3schools are a reference (which according to some is harmful to the web), a few new references have recently popped up from the browser vendors.

Mozilla Document Center is by a stretch my favourite. It's a rapidly growing wiki-based documentation and more often than not it will have what you need. The HTML, CSS and Javascript documentation is really excellent, and going there directly often beats googling.

A bit ago I received the news I'll be a speaker at the Dutch PHP conference. My talk is titled 'So you think you know REST'. Most of you seem to have a general idea what 'REST' and being 'RESTful' means, but often times there are misconceptions.

REST is called an 'architectural style', which means there's not one specification or standard you can work off. So most of the talk will really cover the pitfalls and best practices of applying RESTful principals in the context of HTTP.

I've done a much longer version of this talk before, so my biggest challenge is in compressing it into a really interesting 45 minute talk :).

The DPC schedule looks very exciting, and I know I am :) I hope you can make it too!

Last Saturday I put up version SabreDAV 1.4.

It's taken a while to get this one out. Much longer than I thought. The result was that there's been very little released over the past few months. In an effort to change this, I decided to release 1.4.0 as soon as possible, rather than when all the features are ready. I believe this is better for the end-user and for me as well (release early, release often, etc).

So there it is. These are the new major features:

• WebDAV ACL support. This part is not 100% done. It can be integrated into existing API's, but there's no central ACL store or ability to modify ACL's through the WebDAV protocol yet. These additional features will be added in subsequent versions.
• CalDAV proxy support. This is a proprietary apple extension, allowing users to delegate calendar access to other users.
• Integrated the 'VObject' library, which provides an easy way to read and write iCalendar objects with an api similar to SimpleXML.
• Added the ICSExportPlugin, allowing you to export iCalendar-formatted calendars.

full changelog

To allow for a proper ACL implementation, much of the 'principal' functionality has been moved from Sabre_DAV_Auth to Sabre_DAVACL. There's a Migration guide available with all the details.

As usual, if you're not ready to migrate to 1.4 because of the API breaks or because it's still considered beta, I'll be maintaining 1.3 for at least another year. However, I'll be doing this on a strictly on-demand basis. So if you need a bugfix backported or a release, feel free to ask on the mailing list.

Lastly, thanks to all the users. The number of deployments and feedback is steadily growing and that's very rewarding.

Download here.

During Rob Allen's ZF2 talk at PHPBenelux an audience member shouted this really useful tip, which I thought was worth sharing.

If you're running PHP 5.3 and you have to use pesky old code that uses long class prefixes (yea, so, pretty much all PHP code out there), you can still make use of namespace features to shorten them.

<?php
use Sabre_DAV_Auth_Backend_PDO as AuthBackend;
use Zend_Controller_Action_Helper_AutoComplete_Abstract as AutoComplete;
 
$backend = new AuthBackend();
?>

Might have been super obvious to most of you, but it just hadn't occurred to me.