A primer for Kolab 3.0 – and ways of getting involved

After several months of development sprint the new Kolab web frontend has been unveiled for RHEL and UCS. We’re in fact quite proud of what our team has achieved this year and hope you will agree:

Kolab Webmail

The main email view

Kolab Calendar

The calendar week view

 

This new web client is building upon the Roundcube Webmailer, considered the best Free Software web mail applications by many, and all changes made have been provided to the respective upstreams. The Kolab specific modules are being hosted by Kolab Systems.

In case you would like to see for yourself how this new client has turned out, we have set up a test & demo instance. You can request an account by sending email with your name, email & affiliation to sysadmin-main+kolab@klab.cc. If you want, you can also request several accounts in the same way to test calendar sharing and such. But please be aware that this instance is running on a fairly small virtual machine, so speed won’t be what you see in a full fledged installation. Also this is a test bed for some experiments of ours, which means there may be occasional breakage. If you find something that is broken and remains broken, please file an issue at https://bugzilla.kolab.org.

This web client is now available for customers as part of our standard supported offering, and for those currently using the Version 2.3 Community Release we have a KVM image that you can hook up against an existing instance to give you the interface right away. We would have liked to provide it even easier, and will probably do something in the future, but for the moment we felt that speed was more important than perfection and so wanted to let you have a look at this immediately.

Because OpenPKG has been on the deprecation path for two years now and no future release will use it, there won’t be the same smooth upgrade possibility. So we felt that one clean break is better than two successive ones over a few years and already did a lot of the cleanup of LDAP idiosyncrasies we had on our radar for some time. This has happened in the 2.4 experimental branch already, but as a result the old web admin interface which was hard-coded against the LDAP schema no longer works. Now of course one could try to hard-code it against a new schema. But then that would be a lot of effort for very little gain.

Knowing that we had reached the end of the line for incremental updates, it was time to jump.

That is why our next community release will be Kolab Server 3.0 as announced last week on our development list. Allow me to give you a little bit of an overview.

Towards new horizons

There will be a couple of under-the-hood changes for Kolab 3.0, and some very visible ones. A lot of work under the hood has already been prepared or begun on the grounds of the Kolab Enhancement Process (KEP) which has produced some pretty good output so far. These address capabilities in the format, as well as updates to match a technological world that has been evolving fast.

Under the hood

When Kolab started using IMAP as a NoSQL storage data base, this concept was not all that well understood by many people, and IMAP itself had only just begun lending itself to this kind of approach through the ANNOTATEMORE draft RFC. This is what Kolab has been using up and until version 2.3, but since this draft has long expired and has become RFC 5464 – The IMAP METADATA Extension, it is time to finally lay ANNOTATEMORE to rest. With KEP 9, we also introduce per-message meta data based on RFC 5257 – Internet Message Access Protocol – ANNOTATE Extension for which we have some plans that will hopefully become clear after the 3.0 release.

More importantly, we are giving the Kolab XML Format & Specification a fairly comprehensive overhaul based on a wide range of customer experience and also because the RFC process has completed two fairly important RFCs for us this year: RFC 6321 xCal: The XML Format for iCalendar and RFC 6351 xCard: vCard XML Representation. These will be the basis of our new Event, Task & Address book objects.

The entire format will be described in normative XSD, the code generated & provided through an API with language bindings for a wide variety of programming languages, making it easier than ever to write a Kolab client. This effort is led by Christian Mollekopf, who has prepared a KEP for the specification, and provided a good summary on the why’s and how’s of this approach, which came out of a community consultation process that took place on the kolab-format mailing list.

Kolab Server: Each box can be clustered individually

We also wanted to emphasize further on one of the great strengths of the Kolab Groupware Solution: Scalability. It is possible to set up the Kolab Server in ways that allow for natural high-availability, load-balancing & site reliability with a granularity of performance monitoring and adjustment that allows each individual component to be scaled up or down as required.

(And yes, we have implemented this kind of setup before. In two separate geographical locations. With all optional components. Built so it can scale up to 100s of thousands of users. Any machine can fail at any point without even disturbing the individual session of the user. It is a thing of beauty of which we are proud. We really wish we could talk about it.)

Naturally we like this aspect very much, but believe it may be possible to do this one better through our client-side technology developed in the recent re-factoring of what to us and our customers is the Kolab Client, and which you might simply know as KDE Kontact. We think this technology has potential beyond the desktop that we would like to explore. To us, it is called Server Side Akonadi.

This should be an interesting experiment, and will hopefully also contribute towards the overall speed, quality and flexibility of Akonadi on all platforms, including the desktop & mobile phone.

This will then be rounded off by the LDAP cleanups which will make Kolab near-fully agnostic towards existing LDAP setups, and of course configuration management updates, of which the most important and most visible will be the new Kolab Configuration API.

What you’ll see

Because we need to re-do the web admin in any case, we decided to do it right and make it a RESTful configuration API. This process is already in full swing with a Python backend and the new PHP based web admin being scoped out by Jeroen van Meeuwen and Aleksander Machniak (a.k.a. Alec) based on a draft by Thomas Brüderli. There is even some documentation already. Once we have a version that does at least what the old web admin did, we plan to wrap this into a 3.0-development release including the new web front end. Please note that this will be the starting point for the public 3.0 development cycle, and not a release you should use productively. Because things will break badly in the process of making all the under-the-hood changes described above.

In any case, the new web client will of course be the other major visible change in Kolab 3.0. But of course we are strongly committed towards keeping the interchangeable components approach of the server intact. So we also hope that people will help to make Horde 4 an option for the Kolab 3.0 server.

Meanwhile we’re getting on with the work, and we hope that some of you will join us. If you’re looking for something fun and interesting to do, what about any of these ideas?

  • Create a GTD module for the web client to complement Zanshin
  • Create a web client notes module compatible with the newer versions of KDE Kontact
  • Integrate a web based XMPP client on the web
  • Integrate ownCloud with Kolab on the server
  • [... please insert your idea here ...]

There is in fact a “formalized” approach in which you can throw your own ideas into the mix. You can find information about it here.

According to schedule, Kolab 3.0 will then see the light of the net in May/June 2012, and your favorite feature could be part of that.

So don’t just watch. Get involved! :)

Be Sociable, Share!

10 comments to A primer for Kolab 3.0 – and ways of getting involved

  • Thanks for this very interesting post.
    For testing purposes it would be nice to have VM-Images. VMWare, KVM or both?

  • We’re likely to provide KVM images as we go along, just as we’re now doing for the new web interface. For VMWare we’ll have to see.

  • Heiner Markert

    Thank you for the interesting post.

    If Horde gets replaced by roundcube, will features currently provided by Horde (e.g. SyncML, ics feeds for up- and download) be provided by other means?

    Are there plans to implement CardDAV/CalDAV capabilities to the server?

  • Calendar import and export can be managed via the Roundcube interface.

    SyncML on the other hand is pretty much dead and has been for a while, also because it has some conceptual issues that won’t easily disappear, and support for it has been waning for a long time, with Nokia having been its last champion to desert it.

    CardDAV & CalDAV are things we would definitely like to do. Right now we have our hands full with the current 3.0 time line which must contain the breaking changes — new features would be incremental, typically — but if you are interested in working on this, we’d be happy to add it to the roadmap for 3.0 or 3.1. The sticky point is that in order to really be interoperable, a CalDAV/CardDAV server must have some kind of client-specific translation logic, otherwise you end up with a vendor-specific iCal/vCard store. So it is a little more work than most people realize. See http://kolab.org/pipermail/kolab-format/2011-December/001569.html for some more background on this.

    In any case: Contributions are welcome!

  • Tolingo

    I’m a very happy Kolab user for a few months now. One of the features that lead me to Kolab was Horde because it is the only one (free) WebMail that I’m aware of that is PGP capable. Correct me but the move to RoundCube will break this feature. I wish that HORDE remain compatible with Kolab someway.

  • There is an OpenPGP module for Roundcube, although not (yet) fully functional. We’re looking into ways of completing that in ways that do not compromise the keys by requiring them to be on the server because otherwise the gain in security in relation to requiring TLS is not all that great.

    But in any case we’re still working with the newly founded Horde LLC & the developers of Horde and will be happy to make sure they can continue to provide Horde on Kolab because we want to enable choice for Kolab users.

  • Tolingo

    Good to hear that.
    Although the keys should be password protected I agree that requiring them to be on the server is a compromise.
    With Horde you have the choice to store the keys in the server or upload them at your convenience.

    Anyway, thanks for the good news.

  • In the same context, you might also want to check out this posting by our systems architect Jeroen van Meeuwen giving you an idea of the refactored web admin panel: http://planet.ergo-project.org/blog/jmeeuwen/2012/02/21/sneak-preview-kolab-web-administration-panel

  • [...] the Kolab Server 2.4 Release So a while back I gave a primer and insight into what would happen with Kolab 3.0, and now we’ve released an out-of-schedule Kolab Server 2.4 – what’s [...]

  • [...] 3.0: Update,overview and release plans Almost half a year ago I had the pleasure to write the Kolab 3.0 primer, and ways of getting involved. Optimistically I scheduled the release for May/June 2012 in that posting. Attentive readers may [...]

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>