With its 1.0 GA announcement this week, Zimbra Desktop is officially launched as an open source, full featured desktop mail client. I’d like to use this occasion to reflect back at an interesting approach that the Zimbra engineering team took in developing this product.
Zimbra Desktop behaves like a classic desktop application. It installs and runs on a user’s computer. Even though it’s designed to aggregate mail, calendar and address book data from many Web services such as Yahoo! Mail and Gmail, it runs and interacts with user independent of any particular Web service. However for anyone who’s curious enough to take a peek under the hood, she will find Web oriented technology at every turn.
Using technology originally designed for the Web in desktop application development is not anything new, let alone unique. Both Microsoft and Adobe have been pushing for their brand of RIA (Rich Internet Application) platforms, namely Sliverlight and AIR, and I have seen quite a few desktop products built on one or the other. Of course Mozilla XUL based desktop applications like Thunderbird and Songbird have been around even longer. However what makes Zimbra Desktop a unique case is the engineering approach. We are developing two products, an enterprise server product and a desktop application, in lockstep in the same code base.
The enterprise server in this case is Zimbra Collaboration Suite Server. It is a carrier grade email collaboration server running at many Fortune 500 companies, universities and large Internet Service Providers. The Zimbra Collaboration Suite (ZCS) has support for many clients, including a state-of-the-art Ajax Web client. So what is the desktop application, Zimbra Desktop? In short, Zimbra Desktop is a special build of ZCS that installs the ZCS Server and the Ajax client on the same user computer, collapsing the client and server tiers into one. In terms of their designated roles, the two products can’t be more different. Using an analogy, if I were to claim that Exchange Server and Outlook client share more than 95% of the code between them, few people would believe me. But the equivalent is true in the case of ZCS and Zimbra Desktop.
We didn’t do this just to be cool. We did it for these benefits:
1) Code reuse – lower development cost
2) Code reuse – lower maintenance cost
3) Code reuse – lower user learning cost
The first two points are self evident. The third point about lower user learning cost is due to the fact that the Zimbra Desktop UI is virtually identical to that of the ZCS Ajax web client, so a user familiar with the ZCS Ajax UI doesn’t have to learn a new UI when running Zimbra Desktop. As a matter of fact many ZCS users are also Zimbra Desktop users, often switching between the two as they move between computers. Moreover, the high level of code overlap between the two products not only makes development cheaper but also brings innovation to market faster, because a new feature added to one is automatically available in the other in most cases.
Here is a component diagram of Zimbra Desktop.
At the core of Zimbra Desktop there lies the “micro edition” of the ZCS Server. The Ajax client talks to the local server in a way not much different from the online Ajax client to a real ZCS server. The most significant addition in Zimbra Desktop is the data synchronization engine, which synchronizes user data in the cloud with data on the local computer disk, making the data accessible even when there’s no network connectivity like during air travel.
Making ZCS Server run on a user computer is easy because a) it’s a Java application that can run on many OS platform, and b) it has enough tuning knobs built-in to be dialed down to support a user of one. The ZCS Web container is Jetty, also a product especially good at scaling up as well as scaling down.
One topic we can’t avoid in any discussion of Zimbra Desktop is its integrated browser, Mozilla Prism. Prism is a simple browser built on XULRunner in the same way as Firefox is a full featured browser built from the same code base. As a solution to render the Zimbra Desktop UI, there’s no more ideal fit than Prism as the ZCS Ajax client runs in Prism out of box, just like in Firefox. In addition, we also rely on Prism’s XPCOM layer and other native bindings for OS integration on Windows, Mac OS and Linux platforms such as Ubuntu, to support features like pop-up notifications and “mailto” link handling. It’s plugin framework allows us to do things like add attachments to emails simply by dragging them from their desktop into the compose area, or upload files to briefcase in the same way. While Prism is a perfect choice for us in developing the hybrid online/offline solutions, I should point out that both Silverlight and AIR can work well for other products. In the case of Zimbra Desktop however, Prism and the underlying XULRunner allow us to best protect our investment in the UI.
Finally, a word on why we still choose to build a desktop application when many are moving in the opposite direction, from desktop to the Web. We believe there’s the need for a mail client to be independent of any Web services and to be under the total control of an end user. While there are now products like Google Gears to allow taking a Web application offline in a generic fashion, in the end a Web application can only offer limited ways for third party customization. Many users spend a good part of their work day with a mail client, so it’s very important to allow the freedom to extend the software to best suit each user’s unique needs to be productive. With Zimbra Desktop, the third party extension mechanism is called Zimlets. This is our standard framework to enable Web service mash-ups that adds additional functionality, like Web conferencing or Twittering, directly into the email application with tight integration. In Zimbra Desktop 1.0, Zimlets can be downloaded and injected by end users; in 1.1, our next major revision, we will provide a more seamless way for end users to explore and manage Zimlets.