IntroToZimlets: Difference between revisions

No edit summary
No edit summary
Line 27: Line 27:
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.  
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 is that it is almost completely server based. The server must create an entire HTML page for every function the user wants to do. This also breaks 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, or delete messages, etc). Because HTML wasn’t designed for rich interactive applications the interface tends to be clunky. The client has no sense of state so the server must do additional magic to keep track of each client. To add functionality to the client a user has to modify the server and do some HTML editing so that the server includes the functionality.
There are a few drawbacks to this model. The biggest is that it is almost completely server based. The server must create an entire HTML page for every function the user wants to do. This also breaks 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, or delete messages, etc). Because HTML wasn’t designed for rich interactive applications the interface tends to be clunky. The client has no sense of state so the server must do additional magic to keep track of each client. To add functionality to the client a user has to modify the server and do some HTML editing so that the server includes the functionality.
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.
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.
The biggest drawback here is that 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, and possibly vendor lock. Expandability is hard because extensions must be written for the same platform the client is in. Extensions can not easily access the Internet and both the desktop application and extensions must be ported to run on different hardware.  
 
The biggest drawback here is that 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, and possibly vendor lock. Expandability is hard because extensions must be written for the same platform the client is in. Extensions can not easily access the Internet and both the desktop application and extensions must be ported to run on different hardware.  





Revision as of 21:00, 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

Zimbra is an integrated email platform that provides integrated email, calendaring, events, contacts and tasks. Zimbra is also open source which allows for expandability and lowered risk to corporations. 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.

File:Zwcsnapshot.png

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

Different Types of Applications

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 is that it is almost completely server based. The server must create an entire HTML page for every function the user wants to do. This also breaks 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, or delete messages, etc). Because HTML wasn’t designed for rich interactive applications the interface tends to be clunky. The client has no sense of state so the server must do additional magic to keep track of each client. To add functionality to the client a user has to modify the server and do some HTML editing so that the server includes the functionality.

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.

The biggest drawback here is that 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, and possibly vendor lock. Expandability is hard because extensions must be written for the same platform the client is in. Extensions can not easily access the Internet and both the desktop application and extensions must be ported to run on different hardware.


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