Why another server?
People often ask us "Why another server?". Why not just use Cyrus IMAP? Short answer is we wanted to design a server from the ground up, with tightly integrated indexing, security, web services APIs, multi-protocol support, client synchronization between all those various protocols, server-side extensions and hooks, calendaring, contacts, etc.
We'll go over these in more detail in coming posts. But let me start with one very important: client synchronization.
What do I mean exactly? Imagine if you could use a web client, IMAP client, and Outlook (with a MAPI connection that talks our SOAP protocol), and if you delete a folder, mark a message as read, etc, then all three clients (all active) updated simultaneously!
Imagine the same thing via two web browser. You create a folder in one window, and in the other window (say Firefox one window, IE in the other) the folder automatically appears. How is this done?
There are two important things happening:
1) our SOAP protocol piggybacks notifications in SOAP responses. Ask the server for an inbox listing, and it will return you the results in the SOAP body, but in the SOAP header, we'll tack on interesting tidbits, like if any folders were created, or if a message was deleted, etc. The AJAX client handles all these notifications and updates it state.
2) On the server-side, all active clients (IMAP, SOAP, etc) maintain a session with in the server. All access to the mailbox happens through the Mailbox class in the server. Any changes made are then added to active sessions, and returned to the clients next time the make a request. IMAP allows for unsolicited responses. Our AJAX client (as mentioned) above gets piggybacked notifications in the SOAP header. The AJAX client also does a NoOp SOAP call every so often just to keep the session alive and get back any pending notifications.
The whole system works amazing well, and was designed/implemented by Dan Karp, one of our core server engineers and architects.
More details are available in our source tree, available via:
http://www.zimbra.com/downloads/
Checkout ZimbraServer/docs/soap*.txt for more info!
We'll go over these in more detail in coming posts. But let me start with one very important: client synchronization.
What do I mean exactly? Imagine if you could use a web client, IMAP client, and Outlook (with a MAPI connection that talks our SOAP protocol), and if you delete a folder, mark a message as read, etc, then all three clients (all active) updated simultaneously!
Imagine the same thing via two web browser. You create a folder in one window, and in the other window (say Firefox one window, IE in the other) the folder automatically appears. How is this done?
There are two important things happening:
1) our SOAP protocol piggybacks notifications in SOAP responses. Ask the server for an inbox listing, and it will return you the results in the SOAP body, but in the SOAP header, we'll tack on interesting tidbits, like if any folders were created, or if a message was deleted, etc. The AJAX client handles all these notifications and updates it state.
2) On the server-side, all active clients (IMAP, SOAP, etc) maintain a session with in the server. All access to the mailbox happens through the Mailbox class in the server. Any changes made are then added to active sessions, and returned to the clients next time the make a request. IMAP allows for unsolicited responses. Our AJAX client (as mentioned) above gets piggybacked notifications in the SOAP header. The AJAX client also does a NoOp SOAP call every so often just to keep the session alive and get back any pending notifications.
The whole system works amazing well, and was designed/implemented by Dan Karp, one of our core server engineers and architects.
More details are available in our source tree, available via:
http://www.zimbra.com/downloads/
Checkout ZimbraServer/docs/soap*.txt for more info!
posted by Roland Schemers at 11:07 PM
0 Comments:
<< Home