What was wrong with eGroupWare 1.x?

From Tine 2.0 - Wiki

This page tries to answer the question, why we were so stupid to reinvent the wheel again. But we are not that stupid! ;-) Just read on...

While eGroupWare 1.4 was working very well for most of our users already, the underlying codebase made it very hard to maintain and extend eGroupWare 1.4 in a economical way. Very often we fixed a bug, which got reintroduced later again. Concepts like "unit tests" were not possible, because the classes were tied to much to each other.

We started to develop a CRM module for one of our costumers based on eGroupWare 1.4. As we liked to give it a modern touch, we decided to implement "live search" for contacts. Everything we needed to implement this kind of feature, got provided by ExtJS. It seemed like a trivial task. Implementing the required eTemplate widget was not that complicated. Also querying eGroupWare 1.4 for the needed data, was not very complicated. It looked very fine, until we tried to save the data using eTemplates. eTemplate is inspecting any data received from the client side. It knows which data it send to the client and it knows which data to expect back from the client. This makes it very safe against unsafe data, but makes it absolutely unusable with dynamic content generated on the client on demand. We needed so disable some security features of eTemplate to get it working.

After we have finished the project, we did a performance analysis of our newly written application. The result was very frustrating. 90% of the time spent to generate the needed HTML content got used by the eGroupWare 1.4 framework and eTemplate. The application logic it self, took only 10% of the whole time spent. You can find more details about the results at this page. It was absolutely not possible to base a AJAX based interface on this infrastructure.

As eTemplate is a rendering engine(it creates static HTML code on the serverside) which does the same what ExtJS can do also(it creates dynamic HTML on the client side), we decided to drop eTemplate, as eTemplate was not ready for our needs. On a side note, this will save about 50% processing time on the server. Which means, that any webserver can now handle twice as much active user. The generation of the user interface now happens completely on the client. We will only deliver the data using JSON.

At this time we planned to rewrite only the user interface and use the old backend functionality. Unfortunately we still spent much more time to initialize the framework with any page request, than getting the needed data from the database. So we decided that we will also need to rewrite the backend classes, but we would like to keep the datastructure in the database the same. Rewriting the backend was not that complicated, because Zend released the Zend Framework at this time. The Zend Framework was providing us classes to handle the database abstraction, caching, locale and timezone handling, creating pdf's and many more. We did not need to reinvent the complete wheel again. Most of the needed core functionality for eGroupWare 2.0 was already done.

As we tried to reimplement the logic of the existing eGroupWare 1.4 classes, we stumbled over many problematic pieces of code. First we decided not change the datastructure, but it hurted us to much, to reimplement the same errors again.

A very good example is the acl class/sql table from eGroupWare 1.4. The same class/table stores the rights which user can use which applications, which user member of which group and which users do share which data. Have a look at Handling of user permissions (grants and rights) to find out, how we have restructured the acl classes for eGroupWare 2.0.

Another good example is the lack proper timezone handling. eGroupWare 1.4 has no clue about timezones. Thanks to the Zend Framework we have now proper timezone handling working for eGroupWare 2.0. Have a look at Handling of DateTime informations to read how we implemented it.

As we only have a limited time to implement all the features we like, we simply had no other chance, than rewriting eGroupWare from the ground and doing it right.