IntroToZimlets: Difference between revisions

No edit summary
No edit summary
Line 49: Line 49:


Zimbra has one more huge advantage. Since ZWC runs inside of the browser which means Zimbra can do anything the browser can. That includes accessing information or other applications on the Internet. Unlike webmail applications (that must have the server changed for every new feature added) or desktop applications (that don’t natively support Internet access) extending Zimbra to communicate with the outside world is simple and easy. There are downsides to the model as well. The biggest is that JavaScript is an interprested language and is therefore relatively slower then desktop applications all things being equal.  
Zimbra has one more huge advantage. Since ZWC runs inside of the browser which means Zimbra can do anything the browser can. That includes accessing information or other applications on the Internet. Unlike webmail applications (that must have the server changed for every new feature added) or desktop applications (that don’t natively support Internet access) extending Zimbra to communicate with the outside world is simple and easy. There are downsides to the model as well. The biggest is that JavaScript is an interprested language and is therefore relatively slower then desktop applications all things being equal.  
<div class="floatleft" width="40%"><span class="thinner">
<div class="floatleft" width="40%"><span class="th inner">
Microsoft and XmlHttpRequest
Microsoft and XmlHttpRequest
The functionality that Zimbra and the rest of the Web 2.0 applications utilize was created by Microsoft.  
The functionality that Zimbra and the rest of the Web 2.0 applications utilize was created by Microsoft.  

Revision as of 22:48, 18 June 2009

Extending Zimbra Joshua Prismon

When you think about the Internet chances are you immediately think about the World Wide Web. However it was E-Mail that was the Internet’s first “killer application.” The most common Email environments, such as Exchange and Notes, are hard to customize which has led to organizations being forced to adapt to how their tools do things, rather then adapting the tools to their needs.

Unlike the chaotic nature of the web, E-Mail tends to be highly structured and centralized. This helps to explain why proprietary applications such as Exchange and Notes have been the only real choice for enterprise messaging. Both platforms are hard to customize which has led to organizations being forced to adapt to how Exchange and Notes do things, rather then adapting Exchange and Notes to their needs.

Zimbra is an Open Source program that marries the best of E-mail with the flexibility and accessibility of the web. In this series of articles Joshua Prismon will teach you how to extend Zimbra to reflect your needs.

Introducing Zimbra

At the simplest level Zimbra is a complete mail and calendaring platform. The platform is capable of sending and receiving email via the standard email protocol that the Internet uses for email: SMTP. Zimbra can also support specific types of email – email about calendar events, tasks, and general documents. All of this functionality can be expanded by developers. In this shortcut we will expand our functionality in three ways. For the first example this document will show you how to integrate syndicated data directly into the Zimbra Web Client. The second example will take that a bit farther by integrate outside data sources into the user’s experience. Finally we will integrate a full application into Zimbra allowing users to be more productive without ever leaving their email. These extensions are possible because Zimbra is open source. Open source not only means that the platform is expandable, but it also is lower risk to corporations. Zimbra can be extended without having to depend on closed APIs. Services can be written in such a manner that they work for your users even if you move to a different platform in the future. Zimbra consists of server backend which sends and receives mail and two web-based front ends. The first front end is the administration interface which allows for easy management of the server. The second front end is that the standard user application: the Zimbra Web Client.

Zimbra Web Client

While it is possible to expand all three components, this shortcut will focus on extending the Zimbra Web Client. Zimbra provides several extension methods that isolate you from the complexities of the ZWC.The first extension method is simply using the Zimbra GUI to integrate data from the Internet. The second is defining a “zimlet” to integrate outside services. Finally we will extend the ZWC using JavaScript.


The Zimbra Web Client (hereafter abbreviated ZWC to save on digital printing costs) looks familiar to anyone who has used products such as Microsoft Outlook, Mozilla Thunderbird, or other web mail applications. Messages can be sent, received, saved, and deleted. Calendars and events can be managed. There is also functionality for contact management, centralized documents, task management and individual user options.

There are some things that set Zimbra apart from other email systems. Unlike webmail systems like Gmail and Outlook Web Access the interface is as rich and responsive as desktop applications. Unlike desktop applications ZWC runs in a browser. Firefox 1.0+, Internet Explore 6+, Safari (with some restrictions), and Opera all run Zimbra, and it looks and acts the same no matter which browser it is displayed in.

However ZWC has one more little surprise that distinguishes it from both desktop applications and web applications.


A Internet Application

There are two popular models for email services today: web mail pages and dedicated desktop applications. The “web mail” approach has become more popular with the rise of free mail services such as Hot Mail. In this approach a user connects to the webmail server via a web browser. The browser requests the start page from the server. The server validates the user. Once the user is valid the web server pulls the email messages using a protocol like IMAP and then converts messages from their native format into html. Finally that HTML back to the client. The user reads, deletes, or composes new messages using different pages that are provided by the server. There are a few drawbacks to this model: [*]The biggest drawback is that the model is almost completely server based. Any change in functionality requires access to the server, where the programmer manipulates the HTML output in a message to contain the functionality. [*]Because HTML wasn’t designed for rich interactive applications, the interface tends to be clunky. The browser buttons (Home, Back, etc.) don't map well to tasks in an email application. The server must create an entire HTML page for every function the user wants to do and send it to the client. This is bandwidth intensive and a drag on performance. [*]The single-page HTML model also breaks the principle of separation of concerns, because the HTML generated is a mix of data, presentation markup, and bits for managing the application (links to other pages to send new email, delete messages, etc). [*]The client has no sense of state, so the server must do additional magic to keep track of each client.

This approach can be contrasted to programs that run directly on the desktop. In this model each machine has a specialized program that speaks its own exotic protocol to a dedicated server which provides email and calendar information back to the client. The server doesn’t need to worry about how to display the data or how to keep track of every user. The desktop application does that for them. The desktop application is written for the local operating system and has access to rich user interface API’s that webmail applications can not access. Of, course desktop email applications have their set of drawbacks too

Different Types of Applications

To access email, users must have the client installed on their machine. This results in more maintenance requirements for IT departments, more investments in hardware and software, location dependence (you can't use your mother's computer to read your mail when your on a visit to her), and possibly vendor lock-in.

Extendibility is hard, because extensions must be written for the same platform the client is in. To run on different hardware or different operating system, both the desktop application and the extensions must be ported. Extensions can not easily access the Internet.


The Zimbra Web Client blends the best features of these two approaches by providing an application that runs in your web browser. Unlike the webmail approach ZWC is an application in its own right. The client downloads executable JavaScript code not static pages. This code then runs inside the browser and communicates with the server much like any desktop application would. However unlike a desktop application the code is downloaded from the server and run without any installation eliminating the vendor lock-in and distribution costs of a desktop client.

Zimbra has one more huge advantage. Since ZWC runs inside of the browser which means Zimbra can do anything the browser can. That includes accessing information or other applications on the Internet. Unlike webmail applications (that must have the server changed for every new feature added) or desktop applications (that don’t natively support Internet access) extending Zimbra to communicate with the outside world is simple and easy. There are downsides to the model as well. The biggest is that JavaScript is an interprested language and is therefore relatively slower then desktop applications all things being equal.

Microsoft and XmlHttpRequest The functionality that Zimbra and the rest of the Web 2.0 applications utilize was created by Microsoft. microsoft was trying to create a proprietary web application that would mimic their Outlook desktop application. To get around the page refresh problems they introduced a new ActiveX object designed to interact directly with the server without needing a HTML reload: XmlHttpRequest.

XmlHttpRequest can fetch or post data to and from the server directly into JavaScript. From there JavaScript can use the Document Object Model (DOM) to change the markup and the data on the page accordingly. XmlHttpRequest is the backbone of ZWC.

Zimbra has only one HTML page: the initial page that loads all the JavaScript code that creates the Zimbra Web Client. Once that JavaScript is loaded Zimbra uses XmlHttpRequest to load data and Javascript dynamically creates the interface that the user interacts with. While props must be given to Microsoft for extending JavaScript in this matter, Microsoft implemented XmlHttpRequest in such a way that it only worked in Internet Explorer. This ensured that the XmlHttpRequest was almost completely ignored outside of Microsoft and even Microsoft ignored it for a while as they let Internet Explorer atrophy. It’s only recently with Firefox and the Google applications that XmlHttpRequest (under its more hip name of AJAX) has become popular and widely accepted.

License Terms

Extending Zimbra by Joshua Prismon is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

Jump to: navigation, search