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:
The main email view
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! đŸ™‚
