As promised here’s an update on a few of the major projects we are working on for the JudasPriest release of Zimbra. Overall, our goal for the release is to innovate around our web app using HTML5 capabilities that run on any desktop, tablet, and mobile device while providing support for native clients using sync protocols.
Here’s what we’re working on.
HTML5 Offline Web App
With our mission to drive advancements in Zimbra into the browser as our primary client experience, so goes Zimbra Desktop. ZD was essentially an offline HTML experience using SQL lite to store data, Jetty to serve our web app locally, and Prism (Firefox) to render the client UI. HTML5 enables us to cache our web app in local storage and provide SQL services, via IndexedDB embedded within Chrome, IE, and FireFox, to store and retrieve a local cache of your mailbox data.
Initially we will support mail, calendar, and contacts and we’re taking the approach of syncing your current working set of data up to 30 days similar to a mobile experience where you typically don’t sync your entire 30GB mailbox. For those that must have their entire 30GB mailbox locally with them at all times, we are continuing to make advancements in the sync protocols and Desktop clients we support…keep reading.
HTML5 Touch Web App
We are completely rewriting our mobile web app using the Sencha Touch Mobile HTML5 Framework optimized for the canvas size of today’s smartphones and tablet devices. Our design goals are to focus on fast triage and quick replies to email messages using touch and swipe gestures while providing a unique Zimbra experience with our tags, flags, and search. Initially we are focused on mail, calendar, and contacts with extensibility in mind. Skinning and theming can be done through standard CSS and the Sencha Touch framework has a broad community of contributors and documentation for those interested in doing more layout changes or building additional capabilities on top of our core solution.
Here’s a screenshot of the Alpha UI:
Exchange Web Services
For those that want a native client experience, we aim to support these types of clients using sync protocols. Just as we support native clients across a wide range of platforms and devices using IMAP/POP, CalDAV, CardDAV, and ActiveSync; we will introduce Exchange Web Services (EWS) support. EWS will allow us to support the latest versions of Outlook on Windows and MAC and even the native Apple Desktop Clients. One of the added benefits to supporting EWS is that there is no need to deploy a client connector (eg Zimbra Connector for Outlook) on the local desktop. EWS is a server side protocol and will make it easier for administrators to support the leading desktop clients without desktop touches. You will still be able to connect the Apple Desktop clients via IMAP, CalDAV, and CardDAV as we are committed to supporting standards based protocols.
Always ON, Carrier Grade Architecture
We’re making several architectural changes to Zimbra’s backend to enhance availability, scalability, patching, and update/upgrades. Zimbra has three major components that represent the mailbox configuration and message data: our LDAP Directory, message blobs, and message metadata. In Zimbra 8, we introduced multi-master replication for our LDAP Directory that enabled rolling upgrades and maintenance of this component without service disruption. We also introduced a new version of our StoreManager API that integrates with cloud storage technologies like Scality and EMC Atmos to provide distributed and highly available stores for our message blobs. In JudasPriest, we will introduce a distributed, shared nothing, and active-active architecture for our message metadata and a separate web app component that can be installed on it’s own server. We already have a working prototype of this architecture in our lab.
Yesterday the Engineering team showed me a demo of multiple mailbox servers with multiple web clients attached to the same mailbox at the same time on different servers. Then one of our server engineers opens Apple Mail connected to the mailbox via IMAP and starts flagging messages. You can see the flags show up across both web clients connected to different servers! This is a truly active-active architecture that not only provides redundancy/failover but load balancing for mailboxes across a pool over servers.
This architecture serves as the foundation to provide rolling upgrades with 0 downtime! Mailbox service nodes can be upgraded with maintenance releases or eventually major versions without end user disruption with control over when a user is cut over to the new version and UI.
I’ll continue to provide more information regarding JudasPriest in upcoming posts.
The Zimbra Team