Thomas Koch - eZ Publish

NoSQL summer at lake constance

nospam@example.com (Thomas Koch) — Thu, 17 Jun 2010 09:31:00 +0200

Have you already started to try out these new storage/database things commonly referred to as NoSQL? (For you google-bot, I'm talking about CouchDB, Cassandra, HBase, Hadoop, Hypertable, MongoDB, Tokyo Cabinet, etc). Well, it's one thing to install and use them but another to understand all the computer science background about them.
Therefor many developers around the world thought to make this summer a NoSQL summer. Local meetings are held in many cities: London, Los Angeles, New York, Paris, lake constance ...
If you like to meet for a beer and learn and discuss about some of the hottest stuff in computing, then come around! Please select the dates when you can join and the papers you'd like to discuss. You can subscribe to email announcements or ical and rss feeds at the lake constance nosql summer page.

Zookeeper for web developers

nospam@example.com (Thomas Koch) — Fri, 19 Feb 2010 10:42:48 +0100

Have you ever developed any kind of distributed system? When doing so for the first time, you're very likely to fall in the trap of the Fallacies of Distributed Computing. I've done so, you'll do so too.
Now zookeeper is an application, that helps you implement many distributed protocols on top of it. The hard work of implementing fault tolerance, assuring consistency and that kind of stuff is done by zookeeper in the background. A zookeeper cluster consists of at least three servers running zookeeper (zk). A client can connect to each zk server and issue read and write requests. Zookeeper guaranties that a write either fails or is consistent and that a read will get you the most recent state.
Zookeeper exposes a filesystem like hierarchy of so called znodes. Every znode can have children but also stores data. The data stored in a znode is assumed to be small (less then 1MB). Clients can subscribe to different events on a znode and will be notified of changes in the znode itself of it's children.
Some usage examples come to my mind, which could be especially interesting for PHP developers:

save the PHP session in zk and have it therefor available to all web servers
save a shopping card
save the online status of a user (for a chat system)
synchronize configuration files
master election: many monitoring servers, but only one is active at any given time
logging system: bookkeeper is a zk contribution, that receives your logs and assures they'll be kept save
create a lock on a document in a CMS

Companies that use zk include Facebook, Yahoo, Rackspace and as rumors tell also twitter.
Now this is all kind and sweet, the only sad thing is, there's no PHP binding yet. There are bindings for Java, C, Python and Perl. So if you're desperately searching what PHP extension you should write next, just take the zk C binding and expose it to PHP!
Maybe you're a student and would like to participate in the Google Summer of Code? It should be possible to find a mentor for this project either in the PHP or zk project.
For GSOC the project could include a PHP session implementation in the extension code and the possibility of persistent zk sessions across PHP calls.
If you're in the region of eastern Switzerland: There'll be a presentation about zookeeper at the Webtreff Kreuzlingen on one of the next mondays.

Going to FOSDEM 2010

nospam@example.com (Thomas Koch) — Sat, 30 Jan 2010 20:52:08 +0100

I'm going to fosdem 2010.

These are things I'd like to attend:

time	room	topic	speaker
10:45-11:30	Janson	Promoting Open Source Methods at a Large Company	Brooks Davis
13:15-13:45	AY	Packaging Java Software for Debian	Thomas Koch
13:40-13:55	Ferrer	CiviCRM: Common goals of FOSS and Not For Profit Organisations	Xavier DUTOIT
14:00-14:45	H.1308	The Maemo Community Council: a case-study in governance	Dave Neary
14:00-15:30	Guillissen	LPI exam session 1	Klaus Behrla
14:00-14:45	Janson	What is my system doing - Full System Observability with SystemTap	Mark Wielaard
14:30-15:00	H.2213	Building Federated Social Networks on XMPP	Tuomas Koski, Simon Tennant
15:00-15:45	Janson	Ganglia: 10 years of monitoring clusters and grids	Bernard Li
15:00-15:30	H.2213	XMPP and the Social Web	Alard Weisscher, Laurent Eschenauer
15:30-16:00	H.2213	PubSub Gone Wild: Info Sharing at Mediamatic	Ralph Meijer
16:00-17:30	Guillissen	LPI exam session 2	Klaus Behrla
16:00-16:15	Ferrer	SIP Communicator: Skype-like conf calls with SIP Communicator	Emil Ivov
16:20-16:35	Ferrer	Kamailio (OpenSER) 3.0.0: redefinition of SIP server	Daniel-Constantin Mierla
16:40-16:55	Ferrer	asterisk: An introduction to Asterisk Development	Mark Michelson
17:00-17:15	Ferrer	csync: Roaming Home Directories	Andreas Schneider
17:30-18:00	H.2213	Jingle Nodes: An Open Alternative to Skype	Tiago Camargo
18:00-18:30	H.2213	Multi-User Jingle: Voice and Video Conferencing with XMPP	Dafydd Harries, Sjoerd Simons
18:15-19:00	H.1302	Spacewalk: Linux Systems Lifecycle Management	Marcus Moeller, Sandro Mathys


09:15-10:00	H.1302	Linux distribution for the cloud	Peter Eisentraut
10:00-10:45	Janson	RepRap - Manufacturing for the Masses	Adrian Bowyer
10:30-12:00	Guillissen	LPI exam session 3	Klaus Behrla
11:00-11:45	AW1.120	My life with HBase	Lars George
11:00-11:45	Janson	Tor: Building, Growing, and Extending Online Anonymity	Andrew Lewman
12:15-13:00	H.1302	Cross distro packaging with (top)git	Thomas Koch
12:15-13:00	H.1308	Shared libraries in Debian	Sune Vuorela
13:00-14:30	Guillissen	LPI exam session 4	Klaus Behrla
13:15-14:00	AW1.120	CouchDB, a database designed for the web and more	Benoit Chesneau
14:00-14:45	Janson	Large scale data analysis made easy - Apache Hadoop	Isabel Drost
15:00-16:30	Guillissen	LPI exam session 5	Klaus Behrla
15:30-16:15	H.1308	Continuous Packaging with Project-Builder.org	Bruno Cornec
15:30-16:15	AW1.120	Comparing the MapReduce way in CouchDB with the SQL way in a RDBMS	Stéphane Combaudon
16:15-16:45	AW1.120	Designing a scalable content management system on NoSQL technologies	Evert Arckens
16:15-17:00	H.1308	Debian Secrets: power tools for power users	Wouter Verhelst

eZ Components Template is not slow...

nospam@example.com (Thomas Koch) — Fri, 09 Oct 2009 13:40:42 +0200

... you may just not have used it appropriately. Fabien Potencier has blogged about templating engines, compared their speed and finally concluded that his own templating engine is the fastest. Not only that, but my beloved eZ Components Template engine, which we use with great pleasure at YMC, came out as the slowest in his benchmark. (Althought he complimented it as "probably the one which have the most features".)

Dear Fabien, I think it's not fair to blog a benchmark without publishing the code you used to do the benchmark! But even without the code and without doing my own benchmark, I can offer some explanations, why eZ Components may have been the slowest in your benchmark and why you've compared apples with oranges. I take the compiled template code from the Twig site:

CODE:

/* Hello {{ name }} */ class __TwigTemplate_1121b6f109fe93ebe8c6e22e3712bceb extends Twig_Template { public function display($context) { $this->env->initRuntime(); // line 1 echo "Hello "; echo (isset($context['name']) ? $context['name'] : null); } }

Thinks to keep in mind from the Twig compiled template:

There's direct output via echo (which is captured by Twig and not directly sent out)
The template variables are sent in the array $context
There's no error check, whether the required template variable 'name' is actually sent to the template
The content of the variables is not escaped

Now let's compare this with the compiled code produced by eZ Components Template. First the template:

CODE:

{use $name} {use $items} Hello {$name} {foreach $items as $item} * {$item} {/foreach}

And the resulting code:

CODE:

<?php // Generated PHP file from template code. // If you modify this file your changes will be lost when it is regenerated. $this->checkRequirements(1,array("disableCache" => false)); $i_output = ""; if ( !isset($this->send->name)) { throw new ezcTemplateRuntimeException( sprintf("The external (use) variable '%s' is not set in template: %s and called from %s", 'name', $this->template->stream, ( sizeof($this->template->streamStack) >= 2 ? $this->template->streamStack[sizeof($this->template->streamStack) - 2] : 'the application code') ) ); } if ( !isset($this->send->items)) { throw new ezcTemplateRuntimeException( sprintf("The external (use) variable '%s' is not set in template: %s and called from %s", 'items', $this->template->stream, ( sizeof($this->template->streamStack) >= 2 ? $this->template->streamStack[sizeof($this->template->streamStack) - 2] : 'the application code') ) ); } $i_output .= " \nHello "; $i_output .= htmlspecialchars($this->send->name); $i_output .= "\n \n"; foreach ($this->send->items as $t_item) { $i_output .= "* "; $i_output .= htmlspecialchars($t_item); $i_output .= "\n"; } return $i_output; ?>

The differences are:

The output is collected in a variable, not with PHP's output buffering. I don't know whether this has a performance impact, but in any case it allows for much greater flexibility in the implementation of the template engine. Thus it's possible for example to
The template variables do not come in a simple array but as an object of type ezcTemplateVariableCollection. This is surely slower as an array, but also allows to do great things.
My favorite eZC Template feature: Every variable needs to be declared at the top of the template! I wish PHP would be that strict.
And now the point which may be responsible for the observed performance impact: eZC Template by default escapes all variables with htmlspecialchars. This is of course configurable and so I could compare template execution time with escaping turned on and of: For an array of thousand elements it more then doubles the time.

So in conclusion: Please post the benchmark code, so that we can debug it and please compare the template engines with the same features turned on or off!

Timeline of PHP quality assurance tools

nospam@example.com (Thomas Koch) — Sat, 26 Sep 2009 16:58:46 +0200

I'll be giving a talk on PHP quality assurance tools next week at the gearconf in Düsseldorf. The event is focused on team collaboration and most of the audience will come from other languages then PHP. Since I'm not a contributor to any QA tool I'll center around the user perspective and the process of establishing these tools in a small to middle web company like YMC.
As an outline for the first part I thought to give an historical view on QA in PHP and therefor made a timeline of PHP QA milestones:
The dates as text:

~1997 JUnit
6.4.2002 PHPUnit 0.1
28.8.2003 PHPUnit 1.0.0-alpha1 Release
13.7.2004 PHP5.0.0
14.7.2004 release PHPUnit2
30.1.2006 eZ Components 1.0
~sept 2006 ZF uses PHPUnit (issue #374)
4.10.2006 first integration of Selenium in PHPUnit
1.7.2007 Zend Framework 1.0
18.11.2007 first release of PHPUnderControl
19.11.2007 Project Mess Detection in PHPUnit
6.2.2008 first release PHP_Depend
march 2009 qualityassuranceinphpprojects.com, thePHP.cc

main sources:

Did I get all this right? Are there things I should have added?

eZ Components: The Good The Bad and the Ugly

nospam@example.com (Thomas Koch) — Wed, 17 Jun 2009 11:07:21 +0200

I've been nominated again for the eZ Components Award. Thanks to eZ Systems for honour and to me employer YMC for the food!
So this is a good occasion to assemble a list I've had in mind for a longer time. In a big project like eZ Components, which has been programmed by many contributors over a long time it is natural, that there are some better and some worse parts. So which components are the good, the bad and the ugly? Maybe this kind of overview could also be done by other users of other libraries too. Then we could assemble a big comparison table of framework or library components and one could pick the best parts of each.
You'll notice that even if I consider myself a power user of eZ Components, I won't give a rating for every component, because there are still a few, I've not intensively used by now. So let's complete this table in a wiki somewhere together!

So IMHO:

Component	rating	justification
Authentication	works	the component should better not handle $_SESSION itself
Cache	not used yet
Configuration	not used yet
ConsoleTools	great
Database	great
DatabaseSchema	bad	You want to have more control over your database schema.
Document	great	first ReST parser in PHP? Also many other formats!
EventLog	great
Feed	great
Graph	great
ImageAnalysis	not used yet
ImageConversion	not used yet
Mail	great
MvcTools	works	too few documentation of best practices
PersistentObject	great
Search	ugly	sorry, but it's not flexible enough for more then the most basic needs
SignalSlot	bad	haven't seen any use case that convinces me
SystemInformation	bad	doesn't comply to ezc coding guidelines
Template	great	stable, fast, easily extensible
Translation	works	Misses the important XLIFF format, but can be extended
Tree	not used yet
Url	bad
UserInput	ugly	see my attempt for a new form component
Webdav	not used yet	but looks very promissing!
Workflow	great

The numbers:

not used yet: 6/25
works: 3/25
great: 10/25
bad: 4/25
ugly: 2/25

GIT vs SVN performance with eZ Components

nospam@example.com (Thomas Koch) — Mon, 30 Mar 2009 09:53:35 +0200

The eZ Components project could celebrate it's 10000th SVN commit this week. This does not only mean, that the project has matured and produced a big codebase, but also that one could easily observe the strenghts of GIT over SVN on this sample.
Thankfully in the same week, an issue was filled, complaining that the SVN checkout of the eZ Components trunk takes ages to complete. Since we at YMC set up a GIT mirror of eZ Components I could do a comparission of checkout duration. Unfortunately my comment with the exact numbers has been deleted from the issuetracker as unrelated GIT-propaganda-spam (as it was :-), so that I can only post the approximate numbers from my memory:

svn co http://svn.ez.no/svn/ezcomponents/trunk ~ 10 minutes
git clone git://git.forge.ymc.ch/git/ezcomponents ~ 11 minutes (fetches full project history, 361 MB)
git clone --depth 1 git://git.forge.ymc.ch/git/ezcomponents ~ 1.5 minutes (fetches only current state)

The above numbers demonstrates two things

With GIT you can copy the whole 10000 commit history of eZ Components in roughly the same time as it takes to get only the current state with SVN.
When fetching only the current state without history, GIT beats SVN by an order of magnitude.

Community GIT repository for eZ Publish

nospam@example.com (Thomas Koch) — Wed, 11 Mar 2009 19:51:42 +0100

The eZ Publish Community came together in january to the International Winter Conference in Barcelona. One issue which has been discussed often at this meeting was how the development of eZ Publish could become more open.
As part of a possible solution, I presented the distributed version control system GIT. A poll made in preparation of the conference, has pointed out that half of the respondents already uses a modified version and therefor a kind of fork of eZ Publish. This number has also been confirmed by the conference participants.
As a result Kristof Coomans, Kaarel Jõgi, and me think, that it is about time, to provide a community GIT repository of eZ Publish and thus allow everybody to work on things like:

make the default install of eZ Publish usable in more community related aspects: forums, blogs. This includes mostly templates and permission setup (no kernel modifications) and help people to get started with eZ Publish.
improve the update mechanism of eZ Publish
replace ezwebin templating setup with something more sensible and more easily themeable, maybe look into blueprint css or some similiar
AJAXify the admin area
include functionality from eZ Components:
- ezcTemplate engine in parallel to old eZ Publish templating
- ezcConfiguration for ini file handling
- ezcDatabase for query abstraction
- ezcAuthentication to allow more authentication mechanisms (OpenID!)

To make it possible, that feature branches can be included in an eZ Publish release, it would be suggested to respect the development guidelines of eZ Systems. These affect not only the implementation itself, but also the development process. The most important characteristic of this process is the split up into these steps:

Requirements Discussion
Design Discussion
Test Driven Implementation
Review

All of this steps need to be done openly on the development mailing list.
My employer, YMC was so kind to provide my working time and server ressources and let me setup a git-svn clone of eZ Publish and an issuetracker.

Why Zend Framework sucks. Part 1/infinite - Exceptions Missuse

nospam@example.com (Thomas Koch) — Thu, 26 Feb 2009 16:27:20 +0100

This is the first entry in a series of posts explaining, why you should never ever consider using Zend Framework. I write these entries, because I see many people considering Zend Framework, without knowing how bad it is and without knowing, that there are better alternatives. I'm very fluent in eZ Components so this is the alternative I propose and use as comparission. Please feel free to add your beloved PHP Framework or Library in the comments, but only when you point out, how it is better then ZF. Tobias Schlitt once found this (or similiar) code:

CODE:

try { $username = $this->_getAccountDn($username); } catch (Zend_Ldap_Exception $zle) { /** * @todo Temporary measure to deal with exception thrown for ldap extension not loaded */ if (strpos($zle->getMessage(), 'LDAP extension not loaded') !== false) { throw $zle; } // end temporary measure switch ($zle->getCode()) { case Zend_Ldap_Exception::LDAP_NO_SUCH_OBJECT: case Zend_Ldap_Exception::LDAP_X_DOMAIN_MISMATCH: throw $zle; } throw new Zend_Ldap_Exception(null, 'Failed to retrieve DN for account: ' . $zle->getMessage(), Zend_Ldap_Exception::LDAP_OPERATIONS_ERROR); }

From: trunk/library/Zend/Ldap.php, Line 689

Things to note:

The message of an exception is checked to control program flow. This breaks encapsulation, since the message belongs to the exception class. It would have been better to make a subclass of the exception class and then use different catch clauses for different exception classes.

The comment says, that this has been a temporary measure. But the programmer should have known, that there isn't something like a temporary measure in programming. Once you've introduced a bad thing, you have to live with it for a very long time. Subversion also states, that this temporary measure has been introduced before January 2008.

Update: Found the appropriate statement in the ZF Coding Standard forbidding the above code:

Don't put important diagnostic information only in the text of the exception method. Create methods and members in derived exception classes as needed, to provide information to the catch block. Create an exception constructor method that takes appropriate arguments, and populate the members of the class with those arguments.

GIT for the eZ Ecosystem - Survey results

nospam@example.com (Thomas Koch) — Sun, 18 Jan 2009 16:36:19 +0100

A few days ago I posted a link to a very tiny survey on source control I made to prepare myself for the eZ Systems Developer Conference in Barcelona in two weeks.
Until now, 28 people took the survey. The unscientific results are:

The second most used and preferred VCS after SVN is GIT.
13 of 28 participants declare to use feature branches with SVN. This number is quite higher then I expected given the pain involved with branching in SVN.
16 people declare to use a patched version of eZ Publish.

Some choosen responses from the free text field: Would you like to get more involved in the development of eZ Publish? Is there anything that holds you back from getting more involved?

Funding
Source code access, eZ is not seen as a Community development project. It is eZ who decides the direction & completes the work.
Ez systems being less and less willing to accept anything from the community.
not any more
Missing a cleary community focused process (comparing to typo3)
long process of approval of patches
I can't ever see eZ allowing community development of the core product, but the use of GIT would allow much better patching options.

Some of the above statements are rather pessimistic in regard to community involvment in eZ Publish development. However I'd like to point out some more optimistic personal views on this topic:

eZ Systems manages to keep the quality of it's products very high, compared to other PHP products. This of course has the drawback of high barriers for involvement.
Good tools for patch review workflows start to appear only since some months.
The eZ Components project is a model for open decision making and documentation.

The survey data:

gitforez.ods, gitforez.csv

BTW.: Want to enter yourself in the participants list of the Barcelona conference on upcoming?

Survey on source control management for the eZ Systems Developer conference

nospam@example.com (Thomas Koch) — Mon, 12 Jan 2009 14:04:45 +0100

Time will be short on the eZ Systems Developer conference. So I'll try my best to be well prepared and meet your interest in my short talk on Git for the eZ ecosystem. You could, however, do me a great favor in filling out a short six-question survey about source control management and eZ Publish.

GIT for the eZ Ecosystem

nospam@example.com (Thomas Koch) — Thu, 27 Nov 2008 13:42:05 +0100

It seems, that my company will send me to the eZ International Winter Conferences. There are four points for me, why I want to participate:

Get to know the people
discus the future development of eZ Publish
get certified for eZ Publish 4
evangelize for GIT

Because there is little time for discussions on the conference itself, I want to start already with the last point: Why is it important for the eZ Ecosystem to use GIT? The easier point is, why GIT and not another distributed reversion control system, like Mercurial, Bazaar or ...?
Well, I'm not totally fixed on GIT, it's just the system I know. But it seems to me, that it has very good chances to get THE next version control system. Let's have a look at only some of the most important projects using GIT:

Linux Kernel
YUI3 (YAHOO!)
android (Google)
X.org and related projects, Compiz
Fedora
GNU Autoconf, Automake, core utils
prototype (Javascript library)
Ruby on Rails
Samba
Qt (Trolltech/Nokia)
Most Debian related projects, if not SVN

This list shows several things. The big projects using GIT is a sign, that GIT is "production ready". (BTW: I think it is a little bit silly from the PHP internals, if they regard GIT as still being to "new" for them.) But the big projects are not only a sign, they also contribute back to GIT. Google developed a toolset for their android project to revise patches, based on GIT. A similiar tool is patchwork from IBM, used to track patches to the linux kernel.
If you look at the type of projects using git, you see web related projects like YUI, prototype or Ruby, you see projects on the operating system level like Samba, GNU and the kernel itself and you see projects from the multimedia area like X.org, Compiz and some media players I've not listed. So if you're an open source software developer, chances are, that you must learn GIT at least to download the sources of projects related to your area of expertise.

But now to the more complicated question, about GIT, the eZ Ecosystem and eZ Publish. There are different and conflicting requirements for the development of eZ Publish:

A stable API that keeps backwards compatibility over long time.
Quick addition of new features.
All copyright belongs to one party, eZ Systems (which is a good thing).
Possibility to integrate third party code.

The list can surely be extended. It may become clear, that it's hard to combine these different requirements in only one central code repository.
GIT would allow us, to make our own changes in or on top of eZ Publish, sharing patches with other eZ Partners and contribute patches back to the "master" eZ Publish branch.

source

The most important thing would be, that GIT eases the update of our patched eZ Publish against a new upstream version. While merging in Subversion is a huge pain, it's a no-brainer with GIT.
It's even simple to automatically run a daily testsuite of the most recent eZ Publish trunk against your patched version of eZ Publish.
I stop here and would love to hear your opinion: Do you already have experiences with distributed version control? Do you also see advantages or do you think it's much too complicate? Just leave your comment!

If you're a web designer working alongside print designers....

nospam@example.com (Thomas Koch) — Thu, 27 Nov 2008 08:46:47 +0100

Oh god, bless the author of this:

If you're a web designer working alongside print designers with little to no web design/dev knowledge, how is your experience?

Teeth-grindingly annoying.

Print-turned-web designers:

Learn the medium you're working in. A five minute video of even the best print advert makes for a lousy TV advert. Likewise, techniques and habits refined by years of print design are often sub-optimal or flatly counter-productive when applied to the web.
For the love of god, give up on pixel-perfect positioning and learn to appreciate flow layout. Sure, it makes design harder... but if you think designing flow layouts is hard, think about us poor schmucks who have to implement the damn things. And if you think flow layouts are ugly, let's see how good your precious pixel-perfect design works when I do something freakishly unusual like resize my browser window.
Print pages are Things To Look At. Web sites are Things To Use. Prioritising aesthetics over usability or functionality is like putting a car steering wheel in the middle of the dashboard "because it looks nicer there". You think it's pretty and a real design coup, but everyone else is laughing at your idiocy (... or swearing at it if the design ever gets into production). Incidentally, I swear if I get one more design through with a "button" image but no pressed button image (or "link" style but no "active/hover/visited" link style) I will personally bite off your head and defecate into your body-cavity. You have been warned.
Conventions are not boring - conventions are your friend. Putting light-switches near doors is a convention. Sure, putting them square in the middle of the ceiling is innovative, but then so is cheesegrating your knees (hey - do you know anyone who's done it?). Innovative means "nobody else is doing it". Accept the possibility that nobody else is doing it because it's a fucking stupid idea.
I don't want to "explore the interface". I want to get in, do my shit and get out again. If you think forcing users to explore the interface is such a good idea, try ripping the labels off all the cans of food in your cupboard. A couple of meals of cat-food, chilli and peaches should demonstrate exactly how "fun" this is.

Pant, pant, pant, pant... pant... ahem.

Webtreff: Content Storage

nospam@example.com (Thomas Koch) — Wed, 05 Nov 2008 15:42:56 +0100

Monday we had the topic of content storage (pdf) technologies at our webtreff meeting. We talked about the content model of eZ Publish, about ideas how it could be improved together with some general database design topics.
We already looked at two other approaches: The Java Content Repository and CouchDB.

Especially CouchDB appealed much to the folks and Benjamin offered to prepare a talk about it for dec/01. The next meeting will be on nov/17, 18:30 about Typo3. For more informations you can join our mailing list.

YMC GIT Wiki

nospam@example.com (Thomas Koch) — Tue, 07 Oct 2008 09:23:59 +0200

At YMC we frequently use wikis for client projects. The wiki then serves as whiteboard for specification and documentation. Normally we use MediaWiki, the engine that powers Wikipedia, for this.
But I personally don't like MediaWiki that much, because it's too feature rich for our purpose, it needs a Database and I'd rather use another Markup Language then the default Wikipedia language. So I searched for an alternative and found WiGit, a very basic PHP wiki which uses my beloved GIT as storage backend. Unfortunately WiGit is still written in a rather ugly PHP4 style so I forked it and am now moving it step by step to use eZ Components.

So far it uses:

ezcTemplate
ezcConfiguration
ezcUrl

The next steps are to integrate ezcAuthenticate to use different means of login, most importantly OpenId, ezcDocument to provide different wiki markups or restructured text and the recently released ezcMvcTools to clean up the index.php.

I'm doing this project for fun together with my collegue Emanuel. If you like to join us, you can find the GIT repository at http://git.koch.ro/?p=ymcgitwiki;a=summary and clone via

CODE:

git clone git://git.koch.ro/git/ymcgitwiki

There is also an Ohloh page for our litte toy project.