IMAP capabilities of the Apache Zeta "Mail" component

I have been quite busy on the Horde Kolab_Storage component these past weeks. That involved working with four different PHP IMAP libraries:

• PHP IMAP extension
• PEAR Net_Imap
• Horde Imap_Client
• Roundcube IMAP

I will definitely summarize the results here at a later point as there are many IMAP and also PHP specific IMAP lessons to be shared.

Right now I was pondering over the Apache Zeta "Mail" component though. It is great that it is available as a stand alone component. And I know it has been described as "Doing mail right". Which it may do.

But when it comes to "Doing mail over IMAP right" I must admit that I'm not so certain. The code seems to be very weak in terms of IMAP capabilities and it apparently supports only a tiny fraction of the complexity the IMAP protocol offers. A complexity that is needed however to perform mail access in an efficient way. And a complexity that is also required for getting Kolab data access right.

What I would like to know is if my quick browsing of the code gave me the right impression. Is there anyone out there saying that the Zeta Apache "Mail" component can actually be efficient when dealing with IMAP? If so I would make the effort in adding another backend driver to Kolab_Storage and include this one in the comparison that will eventually result from the recent Kolab_Storage refactorings.

Horde 4 presentation at CeBIT 2011

Next month CeBIT 2011 will start and there will be a short presentation about Horde 4 at the Open Source Forum. It is scheduled for 2nd March 2011 at 16:45.

In case anyone wants to meet with developers from the Horde team during that day or around that day, some of us should be available in Hannover. Hope to see you there!

Edit: The schedule of talks for the Open Source Forum

Horde 4/Kolab road map update

The roadmap for Horde 4/Kolab that was published in November needs some adjustments. This represents an updated version:

• [06.12.10] COMPLETED - Horde 4 Portal + Mail
• [22.02.11] Horde 4 Calendar (alpha)
• [22.03.11] Horde 4 Addressbook, Notes, Tasks (beta)
• [12.04.11] Horde 4/Kolab Final

There were several factors that made the corrections necessary:

• The Horde/Kolab integration machinery needs some more work to allow using the new Horde 4 IMAP capabilites to the full extent in order to benefit from a major performance boost. This delays the release of the calendar.
• The number of pre-releases initially planned was just too high and needed to be reduced. This joins the releases of the other applications.
• The Horde development team decided on a final release date for Horde 4 so it is now possible to add a release date for the first stable Horde 4/Kolab release.
• Releases were switched to Tuesdays.

You are encouraged to watch the Horde commit stream. There are a lot of Kolab related commits flying by at the moment. More on the changes soon.

Ubuntu based Kolab-Server on EC2

During the last two years p@rdus published the new Kolab Server versions as ready-to-go Amazon EC2 images. These images were always based on Gentoo.

This base platform has recently been exchanged with Ubuntu as the underlying distribution. Since yesterday there is now a Kolab-Server-2.2.4 available as an image to be started and used for quick testing. You can expect all upcoming server version to be also based on Ubuntu. This does of course include the Kolab-Server-2.3 that will hopefully be released soon.

Instructions on how to use the Kolab Server images can be found in the Kolab wiki.

Horde Project Newsletter

The date for the next Horde4 release is drawing nearer and we felt it makes sense to provide another news channel for the Horde Project.

So we are getting ready to launch a new newsletter that will keep you up-to-date on the progress of the Horde Project. Delivered around once per month, it will contain highlights of the Horde project's development and provide insight into our features and project plans.

To receive Horde news please click here to sign up!

We promise to respect your privacy and will never share your email address with a third party.

Horde release cycle

• Horde 1.0.0: 1999
• Horde 2.0: 2002
• Horde 3.0: 2004

... and finally Horde4 in 2011.

The gap between 3.0 and 4.0 has been too large. The Horde team tries to keep backward compatibility within a major version. Probably nobody tried running a recent Kronolith from 2010 on Horde 3.0 from 2004. There'd probably be some issues and limitations but they should be minor.

While this kind of long term support may be useful for some edge cases it can also impede development progress. A good example are the Kolab drivers in the currently released version: Kolab support within Horde started to improve in 2006. At that time Horde3 was already the active branch and there was some very basic Kolab functionality in there. So the new code had to keep those interfaces stable. Which basically meant twisting and bending it into code that would do just that but otherwise be really problematic. That code is still a reality in the current stable release from Horde3.

This and similar problems did not pass unnoticed though and changes to the release cycle have been discussed internally for a while already. With the release of Horde4 approaching it now makes sense to discuss such changes with the Horde community. The envisioned target is a time based release cycle.

The discussion started today on the Horde development mailing list. Feel free to listen in or to add your own comments if you want to influence the direction of our future release mode.

Hudson Quickie

After my third Hudson repository using the same installation procedure it was definitely necessary to finally extract the whole Hudson specific part into its own repository.

It is nothing fancy as the installation procedure with Hudson is pretty straightforward anyhow. But maybe you want to get Hudson quickly running on your own Linux machine with a few standard plugins pre-installed. Then the repository might be exactly what you need.

Just clone the repository with

git clone git://github.com/wrobel/hudson-install.git

and follow the "Install" instructions in the README. Of course you can also just fork the repo in case you need your own predefined set of plugins installed into Hudson.

The Horde4 package mill for Debian

As mentioned before p@rdus intends to provide Horde4 packages for Debian beside the Kolab specific OpenPKG based build. The first steps of this process have been taken now and another Hudson based package mill has been created for the task. The new system bundles Horde4 packages for Debian after each upstream commit and lives here.

This is just considered a first step on the way to a full Debian release as there will be a fair amount of quality control required to get the packages fit for wider distribution. In addition the exact policy on how to handle PEAR packages on Debian is apparently still under debate. p@rdus will join this discussion now with a set of more than 50 PEAR based packages in tow.

The timing for this seems just right as there are still a few weeks left until Horde4 will see its first release. So there should be enough time to ensure that there are no major conflicts between PEAR based and Debian packaging.

An early Horde4 release for Kolab-Server-2.2.4

A while back p@rdus promised an early alpha of Horde4 for the Kolab Server for today. Which would have been followed by the release of the Horde4 mail client and the new mobile mail view in the following weeks. But as the Horde developer team has been quick to provide the new mobile view there is no need to delay the delivery of the mail client and the mobile portal any further. So you get a little bit more than promised today but as it is St Nicholas' Day that seems to be just fair.

Of course all the usual warnings apply. This is an extremely early packaging attempt. It is not well prepared and the installation procedure is flawed. There will be no upgrade path. Doing the following on your server has a high chance of damaging the system. Do not even think about installing the packages on a productive machine. In addition the packages just install the mail part of Horde and won't provide a lot of new functionality. And since there are tons of issues the stuff that is new is likely to be broken.

But those of you who have a spare machine with a throw-away Kolab Server 2.2.4 can try to install the packages using the following steps (this assumes your server is up and running):

wget http://files.pardus.de/horde4-20101206.sh
chmod u+x horde4-20101206.sh
./horde4-20101206.sh

You should be able to access the Horde4 installation at http://your-domain.com/client4.

Any kind of feedback is of course appreciated and will be used to improve the packages during the months to come. p@rdus will also continue testing and bug fixing of the packages while the final phases of the Horde4 development continue.

Now there are no December items of the roadmap left. So p@rdus will continue the next weeks with highlighting the new elements you can expect to find in Horde4. This should be accompanied with a few bug fix releases. In addition it is planned to provide you with a demo server in case you do not have a spare machine to test the new packages. So stay tuned!

PHP library release survey

Tobias Schlitt is asking PHP developers and users about their preferences concerning the release process of PHP libraries. I figured I spread the word and provide you with the link to the survey.

The survey itself originates from an ongoing discussion on how to release Zeta components. It will certainly not allow to extract a generic guideline on how to release your PHP code but I think that is also not what the survey intends to do.

The central question of the survey "What is your preferred way of installing PHP libraries?" does only have one correct answer after all. But that one varies depending on the person asked and on the installation target.

"Man, I clicked this cool button on my webhosters site and now I got this webmail installed in just one go. What a nice custom installer!"

"I just love Ubuntu. I even have that on my server. If I need a PEAR IMAP library I can just apt-get install pear-horde-IMAP_Client. If I need Horde I run apt-get install horde4. And I get all the security updates automatically! Using your distribution or OS is really the only choice there is."

"I downloaded Horde and installed it on my dedicated server. Set it to run on lighty and it's blazing fast. I connected it to our LDAP user DB. Now I still need to get the Facebook and Twitter API keys so our users can connect to their accounts there. Unpacking and installing the tarballs was no major deal."

"I'm a PHP developer and I want to code a small application that needs to handle IMAP. It needs to be better than the IMAP stuff from PHP. But I don't want to code the protocol handling myself and I don't want to pull something totally unstable from a repo. And please don't give me a full framework. I just need IMAP. Oh, and in a year I might want to upgrade in case there were fixes to the package. Can I get Horde_Imap_Client via PEAR please?"

"Huh? I code Horde, I do some PEAR. Sometimes I pull stuff via the OS. For customers the tarballs are great. But at the end of the day: There is only git."