The technology behind the classic and new interfaces

I recently wrote a postmortem for our old interface, now I want to explain how the addition of a modern interface alongside our classic interface is different.

In short, classic is here to stay.

For all that the interface has looked similar over the past few years, it’s had many changes under the hood.

Much of the interface is fully internationalised, both in classic and new. The code is all shared with the My Opera Mail product, where multiple language support is a core requirement.

It works much more nicely on small devices, in particular with Opera Mini.

Where possible, changes for the new interface have been rewritten as shared “library code” and integrated into both interfaces simultaneously. Some things (search, for example) work differently. But most core logic, and of course all low level mail routing and storage, are fully shared across our infrastructure.

This all adds up to a pile of “invisible” work we have done to make maintenance easier in future. Even the new search uses the same query builder library, so back-porting fully cross-folder search capability to classic will be achievable if there is demand.

Unlike the old interface, which was a completely separate copy of the code and grew stale over the years, there was never a “fork” (as it’s called in software development) for the new interface.

Indeed, you may have noticed that many screens on the new interface are really just “rebranded” classic. It’s the same HTML code as the classic desktop and mobile screens, with a different title bar. When you go back to the Mail or Address tabs, it reloads the javascript and hands control back. This was a deliberate decision to speed up the areas of our site where people spend 99% of their time (statistic taken from logs, not made up) without duplicating the rarely used screens. The client-side mailbox screen uses less bandwidth and is more responsive than the classic mechanism of downloading an entire html page on every click.

When we say “supported indefinitely” it really does mean that we have no plans to remove classic. There’s no internal timeline in our heads. The core technology is used by both interfaces, and we’re updating them together.

Finally to address concerns about continued IMAP access.

We have invested heavily on improvements to the Cyrus IMAP server, both myself and Greg Banks in the Australian office (who was hired to work full time on Cyrus, and is doing an awesome job).

Our new conversation features are built directly into Cyrus, and fully integrated into its replication system. Other features like storing previews and undelete information along with messages have been created by adding support to Cyrus for the standard message annotations described in RFC5257, contributing that work back to the community.

You can read more about the Cyrus project at http://cyrusimap.org/. This reliable and standards compliant server is the core of our technology stack. We’re not moving away from IMAP, even as we extend the server to support our specific use-cases.

You can read (or even download and play with) the exact code that runs on our servers from
http://github.com/brong/cyrus-imapd/ - our production systems run on the “fastmail” branch.

Bron.