Programming

Contributors to the Zend Framework must first sign a Contributor License Agreement (CLA) before they're allowed to commit anything. This is claimed to make the Zend Framework "IP clean", so big corporations have no problem adopting it. I've never believed in this proclaimed need of being "IP clean". Maybe that's because stealing someone's proprietary code never came to mind - am I just to good a person? However, in a world where in certain strange countries (I won't drop any names here ) you can actually patent software - or worse, ideas - it is increasingly difficult to write a single line of code that you can be sure of not violating anyone else's so-called intellectual property. In the FAQ for the CLA there's one phrase that I do not get in this context:

By having a CLA in place, we mitigate the risk of companies like SCO claiming intellectual property infringement and coming after users of the Zend Framework, whether individuals or companies, for licensing fees.

How is this possible? Granted, a few lines above it says "to the best of the contributor's knowledge", but still, how can Zend make this claim? How is it possible to know for any individual contributor that his code doesn't infringe software patents of some patent troll, like SCO, without spending insane amounts of time/money? This is easily answered: It is not possible. Thus, I don't think the CLA has any legal meaning whatsoever. It's just a marketing instrument to help sell the Zend Framework to corporations. It would be fairly interesting to know, though, if Zend, if they must insist on signing a CLA like that, is planning on offering any kind of protection against silly patent lawsuits in case a troll comes along. What? Is there any point I'm getting to, you ask? Nope. Just ranting and wasting your time

Just as threatened in my last post, I'll describe the first component of my upcoming eZeAR framework: The ActiveRecord implementation. Since Alan Knowles' great DB_DataObject package crossed my path a few years ago, I've been using object-relational mapping as much as possible. It makes my code a lot more readable than embedding raw SQL queries whenever I need to get the tinyest bit of data out of a database. It also helps dividing the model (or business logic, if you will) from the controller and view scripts (which I have often intermixed for the sake of simplicity). Frankly, I've never looked back. I still like DB_DataObject a lot, mainly for its simplicity and flexibility. But it has some drawbacks: When working with large recordsets (tens of thousands of records), its caching mechanism ate up so much memory, that it had to be deactivated in batch processing scripts. Also, in said scripts it became apparent that performance wasn't quite what I'd like it to be. In my usual use-cases (intranet applications with master/detail views and a relatively small number of concurrent users) this didn't have much of an impact, but with really huge databases and batch-processing of huge amounts of data, it was a bitch. Just by reimplementing a batch script using pure PDO calls and hand-written SQL as opposed to DataObject I was able to cut down script runtime immensely. The script's job was to iterate over about 18.000 XML files, normalize the flat data structure and insert it into a schema consisting of about 30-40 database tables. The DataObject-based version of the script ran over one hour. The PDO version took about 6-8 minutes (mind that it was an older version of DBDO, so this may have changed in the meantime).

It's been a while since I've contributed to an open source project - not because I've suddenly grown some kind of dislike towards OpenSource, on the contrary, but simply because I had no more time to deal with all the feature requests, bug reports, support questions... it simply became too much and I had less and less time to cope with it all. Thus, for a long time, I did not publish one tiny line of code. This is about to change again, although this time I won't contribute my code to any of the "big" projects out there - this brings too many obligations, and I still don't have a lot of time to spend. So I'll just set up a publically-accessible SVN repository and report my progress here. Maybe Planet PHP will pick up my blog so the world will even hear about it The desparate search for my new baby's name (the blog title will prove that I'm not too creative when it comes to finding good names), that would also act as a namespace for its classes, has currently ended at the bulky word "eZeAR". This reflects that I'm about to use the best components from eZ components, the Zend Framework and PEAR - but mainly it just reflects on my hope that it will make my life, well, easier