Zimlets XML API Introduction


Zimlets™ are a mechanism for easily integrating the Zimbra Collaboration Suite (ZCS) with any Internet or intranet information system/application that provides an XML/web services bindings. We also use the Zimlet approach to “mash-up” (intermix) user interfaces within the Zimbra Collaboration Suite itself, such as by mashing up calendar and contacts within your email so that you need not switch back and forth. While the Zimlet Specification was designed for the Zimbra Collaboration Suite, the model could be easily be generalized for other Web 2.0/AJAX user interfaces.

Web 2.0 and Email

Web browsing and email/messaging are the two “killer applications” of the Internet. Many (or even most?) power users devote more time to their messaging/calendaring application than any other networked application, and yet that messaging/calendaring application itself has typically failed to keep pace with the technology advances of the Internet.

The Web is a “pull” experience in that the user initiates synchronous requests for content or services, while email and messaging (instant messaging, voicemail, etc.) are “push” experiences in that content from others (often too much content) is asynchronously delivered (or “pushed”) to the user. For the user, the separation between the browsing (pull) and messaging (push) paradigms can be frustrating—how much user time is wasted cutting and pasting content from email into the browser in order to take action based on message content? If we can successfully blend more web functionality into messaging applications, we can both improve user productivity for email and reduce the gap in user experience between push and pull.

Web 2.0 technologies like Asynchronous JavaScript and XML (AJAX, which is the topic of another Zimbra whitepaper) and XML/web services, and next-generation collaboration solutions like Zimbra that leverage AJAX and XML, have the power to change that by integrating “push” and “pull” within a single unified model that empowers users to switch back and forth at will. Web 2.0 (buzzword “du jour”) really encapsulates three things:

  • Richly-interactive user interface in the browser – With technologies like AJAX, web UI can be every bit as rich as that of traditional client/server applications, but at the same time still have all the look, feel, behavior, and zero client administration of the World-Wide Web;
  • XML-based web services – Service-Oriented Architecture (SOA) based on XML end-points allows Internet data and services (maps, stock quotes, weather, flight status, etc.) and intranet data and services (enterprise applications such as CRM, ERP, etc.) to be securely accessed from other applications and systems; and
  • Mash-ups – Mash-ups are the aggregation and customization of multiple web user interfaces and web services to eliminate context switching between existing systems, deliver wholly new experiences, or almost the range of everything in between.

Zimlets, as we shall see shortly, are an extensible mechanism for marrying Web 2.0 technologies to enterprise messaging (e.g., email, IM, voice) and collaboration. With Zimlets, arbitrary message content can be made live by linking it with web content and services on intranets or the Internet. No more cutting and pasting from email to browser. “Mousing” over actionable content gives the user a real-time preview (subject to security constraints) that can be factored in decision making:

  • Mouse-over a date or time, and see what’s in your calendar;
  • Mouse-over a phone number, and see what’s in your address book;
  • Mouse-over an physical address, and see a map or even driving directions and estimated arrival time;
  • Mouse-over a flight, and see whether or not it’s on time;
  • Mouse-over a customer email address or case tracking number, and see its status;
  • Mouse-over an equity to get a quote;
  • Mouse-over a part number to check inventory;
  • Mouse-over an Internet order, and see its shipping status; and so on.

With Zimlets, email (as well as IM, calendaring, etc.) content can also be fully and securely actionable:

  • Right click on a phone number to make a call with your soft-phone (such as via Skype or a Cisco VoIP phone);
  • Drag an email to an SMS icon to edit/forward to your co-worker’s phone;
  • Drag an email, contact, or appointment to an IM session with a buddy;
  • Right click on a bug/customer case to escalate its priority;
  • Drag a song or book title to iTunes, Amazon, etc. to initiate a purchase;
  • Drag a message, conversion (collection of messages), contact, or meeting summary to your CRM system icon (such as Salesforce.com or SugarCRM) in order to archive and share that data across your sales team;
  • Cut and paste a word to Wikipedia to review the definition;
  • Drag a contact to Yahoo! or Google maps to see where they are located;
  • Right click on a name, address, or phone number to update your address book;
  • Right click on a date to schedule a meeting;
  • Drag an email to your calendar to schedule a meeting for participants on the thread (and share the annotated email conversation as background);
  • Right click on a airline reservation to print your boarding pass;
  • Right click on a part number to place an order for more inventory;
  • Right click on a purchase order, provisioning request, or other internal workflow request to approve or reject it; and so on again.

What Makes Zimlets Different

For years, email applications have been highlighting and linking the text of obvious web content - such as URLs and email addresses: when a user clicks on the highlighted text, the email application takes the appropriate action:

  • Launching a browser window to open the web page associated with the URL, or
  • Opening the email editor so that the user can fill in the body of a message destined for a particular email address.

The beauty of this approach is that all the “smarts” are on the receiving end: The author of the email is not obliged to “tag” something as a URL or email address. Rather the receiving email application simply recognizes these magic strings and then links them for ease of user action.\\ Unfortunately, this mechanism has generally not been extensible: the user gets precisely what linking the email system supports_ _“out of the box”, and extensibility is where the real productivity pay-off lies. Imagine if:

  • Email from customers could be auto-linked to the customer support and CRM systems;
  • Email from suppliers and redistributors could be auto-linked to inventory management, manufacturing control, and accounting systems;
  • Email regarding a particular derivative could be auto-linked to trading and risk management systems; and
  • Email regarding a new employee could be auto-linked to the appropriate HR systems.

The same holds true for insurance claims, provisioning requests, retail sales reports, and so on.

There have been a couple of prior approaches focused on _extensible _linking and actionable content. Most placed the burden of linking the content on the author of the email. This is problematic for emails that originate with customers, business partners, or even employees on their home computers, all of which often rely on email software that is other than the end user’s internal standard. Far better is to have the smarts on the receiving end so that actionable email works with for all in-bound email whatever the source!

Other approaches to extensible linking and actionable content, such as Microsoft’s Smart Tags, were developed for Office desktop applications (Excel, Word, Outlook, etc. as well as Internet Explorer/IE). Approaches that rely on such client-side installation and execution of the linking and action defining code are problematic in that they do not offer:

  • Multi-browser, multi-operating system* – The Zimlet approach will work in any standard Web browser (IE, Mozilla Firefox, Apple Safari, and so on) and on any client operating system (Windows, Linux, MacOS, and so on) without requiring the _installation_ of any software. (Zimlet AJAX code can, however, be downloaded with the Zimbra Collaboration Client for interpretation by the Web browser.)
  • Multi-client* – Zimlets are also designed to work across the range of client devices that support the Web such as mobile phones, PDAs, tablet PCs, set-top boxes, and so on. Any client device that supports the Internet-standard Web model of AJAX works with the Zimlet architecture.
  • *Object recognition across mailboxes* – With the server-side execution of Zimlets, actionable objects are recognized on the server which permits them to be indexed for _search/discovery across mailboxes_ such as is required for Sarbanes-Oxley or Human Resources compliance, fiduciary isolation of business units (such as automatically recognizing equity-related communications) and so on.
  • Reduced administrative overhead* – Installing and maintaining client-side DLLS is expensive and error-prone. Zimlets that are depoyed within a Web 2.0 framework like the Zimbra Collaboration Suite, can be automatically updated with each browser session and therefore, have zero administrative overhead on the client side.
  • Security *– Client-side DLLs are also a security risk, particularly when they are permitted to access to client data or arbitrary services on the Internet. Zimlets instead run under the protected execution model of the Browser and hence are precluded from touching client data or from communicating with Web sites other than the web front-end for the Zimbra Collaboration Suite itself (which securely proxies requests to other web services and user-interfaces. Moreover, the server-side code for Zimlets is deployed as Java managed code which provides more protected execution from errant Zimlets inadvertently or maliciously interfering with Email operations.


Zimlets are the first actionable content model designed to leverage Web 2.0 technologies-- AJAX, XML/web services, and mash-ups. Most Zimlets can be specified declaratively in a simple XML definition file that specifies the UI, behavior, and URL endpoints associated with the Zimlet. While Zimlets allow the definer to “drop” into JavaScript (client-side) or Java (server-side) code order to provide rich, highly customized behavior, the vast majority of Zimlets are “weekend projects” that are fully characterized via that declarative template.

At the same time, Zimlets are designed to address enterprise deployment constraints:

  • Under Zimlets, the pattern matching/linking is done on the server-side, where customizations can be centrally installed and managed by the messaging system administrator.
  • Security, too, is managed on the server-side under the AJAX –based Zimlet model; a client’s requests are routed via a secure, managed server that can proxy the client’s security privileges as appropriate.
  • Zimlets run under a protected execution model (much like JSPs and Servlets) in a manner that prevents them from inadvertently or maliciously interfering with other processing on the system.

Zimlets are realized in the client in two ways:

  • As panel item elements in the application overview panel. The user may interact with Zimlet panel items by dragging content such as mail messages, contacts and calendar appointment onto them, double clicking them, and invoking actions from a context menu, if one is provided by the Zimlet author. The two images below show the result of a user dragging and dropping a contact onto the “Salesforce” Zimlet panel item.

Overview Panel

The image below shows what happens after the dragged item (a contact in this instance) is dropped on to the Zimlet:

Example of Drag and Drop on Zimlet

  • As Content objects, such as phone numbers, purchase order numbers, and URLs in content such as email message bodies, contacts, and calendar appointments. The image below shows the result of hovering over a URL Zimlet content object in the body of a mail message.

Zimlet action

The Zimlet architecture was designed with the goal of enabling a broad range of Zimlets, from those requiring little or no custom code (i.e. entirely declarative) to those which use JavaScript to tightly integrate rich UI behavior within the Zimbra Collaboration client.

The Zimlet architecture consists of a client and server framework, as well as a set of web services and JavaScript APIs. Zimlets are exposed to the end user via the ZCS AJAX client. The Zimlet server infrastructure provides the mechanism for lifecycle management such as deployment, configuration, access control, and “undeployment” of Zimlets. In addition, the framework provides the ability to integrate Zimlets with the ZCS search engine. The Zimlet client framework helps realize Zimlets in the ZCS AJAX client. The framework provides support for drag and drop, context menus on both panel items and content objects, and for embedding of Zimlet content into the application. The details of these will be presented as part of this document.

ZCS comes preconfigured with several Zimlets that provide illustrations of what is possible. These include: Integration with Yahoo/Google Maps, Alexa, Amazon, Bugzilla, ZCS calendar, ZCS address book, and Skype.

The Zimbra Community website will serve as a clearing house for innovative Zimlets that various independent developers and enterprises devise. We hope to bundle the most compelling, and generally useful 3rd-party Zimlets into future releases of the Zimbra Collaboration Suite.

Verified Against: Date Created: 7/28/2009
Article ID: https://wiki.zimbra.com/index.php?title=Zimlets_XML_API_Introduction Date Modified: 2015-03-24

Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »

Jump to: navigation, search