Mobile messaging with open source

History teaches us that seemingly small events can quickly balloon into much larger problems. Take the assassination of Archduke Franz Ferdinand of Austria on June 28, 1914 — an isolated incident that, in four months, escalated into World War I. With somewhat less catastrophic results, the introduction of a new technology can cause surprisingly large ripple effects in the enterprise.

Recently, the executive team at InfoWorld decided to test the Treo for mobile messaging. The IT department was asked to deliver e-mail to the devices. We thought our existing infrastructure would easily handle this. But within a couple of days, our simple need to deliver mail to the Treo blew up into a much deeper analysis of our current environment. Ultimately, we triumphed, but not without learning a few lessons about the realities of implementing open standards in enterprise IT.

Although standards support atop traditionally proprietary systems is a good and noble thing, performance issues often arise. Standard interfaces are typically built on a proprietary stack, incurring translations that hobble performance. InfoWorld uses Lotus Notes for e-mail, and although Lotus Notes supports POP3 and IMAP for e-mail retrieval, we hadn’t exercised Notes support for these protocols in a low-bandwidth, wireless environment.

We assumed that a standard POP3 client on the Treo would be capable of quickly grabbing mail from the Notes POP3 server. We didn’t think about the performance hit that would be incurred when the POP3 server had to convert each message on the fly from the Notes RTF to standard MIME. (We could have forced Notes to convert all incoming mail from RTF to MIME, but that would have inconvenienced our larger Notes user base.) In a wireless, superthin-client environment, this POP3 delay on the server side was a deal killer.

Originally, we wanted to use the smarter IMAP protocol to feed Lotus Notes mail to the Treo. After our POP3 problems, we decided to try IMAP but quickly ran into a roadblock. Some of the wireless IMAP clients required support for the IDLEcommand on the server side to enable the server to notify the client when mail arrived. Our Notes IMAP server didn’t support the IDLE command. At that point, I could have offered the all too common but often lame IT excuse: “We don’t support that.” I was growing impatient with our inability to handle something that seemed so simple, and I wasn’t willing to go through the pain of filing support tickets and waiting for patches. My IT staff needed to get under the hood to fix this, but the hood was welded shut.

Enter open source. When you want highly configurable, standards-based functionality for services involving basic Internet plumbing such as e-mail and the ability to finely tweak configurations to meet your specific needs and performance requirements, open source is a solid bet. Within a couple of days, we had compiled, installed, and evaluated both the University of Washingtonand CyrusIMAP servers, and mail was flowing to the Treos via standard IMAP running on a cheap Linux box. There is nothing spectacular about either package -- both do only what you would expect and nothing more. But for highly configurable IMAP functionality, we got exactly what we wanted -- and that’s all we needed.