There's much more to GMail's support of IMAP than meets the eye

If you're like me and you saw last week's announcement from Google regarding GMail's support of the IMAP mail retrieval protocol (and you know what IMAP is), then you probably reached the same conclusion I did: Given the way GMail lets you tag e-mails with labels (as opposed to the way most other e-mail systems handle e-mail organization via foldering), Google has come up with a way to synchronize labels in GMail with folders of the same name (as each label) in your e-mail client. Typical clients could be Outlook and Thunderbird, or a smartphone like a Treo, iPhone, or BlackBerry. If you reached that conclusion, you were right. But, based on my podcast interview with GMail associate product manager David Murray, there's a bit more to the IMAP announcement than meets the eye.  Through the embedded player above, you can playback the audio, download it, or, if you're already subscribed to ZDNet's IT Matters series of podcasts (see how to subscribe), the interview should appear on your PC, MP3 player, or both (depending on how your subscription is set up).

Most e-mail clients support IMAP. But not most e-mail services (like GMail, until now). As opposed to the POP3 protocol that pretty much every e-mail service and server supports (the alternative to IMAP that e-mail clients can use to retrieve e-mail from e-mail servers and services), IMAP supports bidirectional synchronization of your inbox as well as any folders that you've created to keep your e-mail organized. I often lament how some of the various e-mail services out there don't support IMAP. First, who doesn't need some way of keeping their e-mail organized? Second, who wants to have separate organizational frameworks on their clients and servers that are completely unaware of each other?

Looking to not only address that pain, but also make its GMail service more appealing to enterprises, Google introduced IMAP support last week and is still in the process of making the feature available to 100 percent of its GMail service users, including users of Google Apps (a bundle of Google services that's targeted at organizations and that integrates GMail with Google Docs, Google Calendar, and other Web-ware offerings).

What, beyond basic synchronization of GMail folders with client-side mail applications, can users look forward to.  One of the most interesting apsects of GMail's IMAP support is the way in which the synchronization process deals with e-mail that's dragged into a spam or junk mail folder on the client side.  For example, as I described in a blog post that I published earlier today, that act triggers the same business process on the server side as the one that would be triggered if, when opening a message via GMail's Web interface, you pressed the Report Spam button. Likewise, whatever rules on GMail's server that may have resulted in the false classification of an e-mail as spam are reconsidered when a user moves an e-mail that GMail put into the spam folder to a folder for legitimate mail.

Another VERY interesting feature of Google's IMAP support is the way in which the tagging of an email with multiple tags results in that same email being filed in multiple folders on the client side.  Provided your email client somehow makes it possible to store an e-mail in multiple folders on the client-side (many don't), the same is true in reverse.

Because of the way IMAP supports the nesting of folders, supporting IMAP meant that Google had to figure out a way to hierarchically nest labels.  So, along with the introduction of IMAP support, Google has introduced the slash ("/") as a means of telling GMail that one label is a parent to another.   For example, in GMail, the parent-label "Northeast" could have child-labels as in "Northeast/Massachusetts" and "Northeast/Connecticut".  On the client side, such a hierarchical taxonomy would be reflected in parent and child folders with no limit to nesting depth.

The introduction of hierarchical tagging begged two more globally directed questions for Google; First, will the hierarchical tagging be made available in other Google services (ie: Google Reader, Google Docs, etc.). Second, when will (note, not "if", but "when") Google's customers be able to unify their taxonomy across those other applications so that users can see everything that's tagged with the same label (eg: "Northeast/Massachusetts") regardless of what service it comes from.

Google can't not do this as there's a strong likelihood that information workers will be collecting/receiving data through a variety of conduits (e-mail, RSS, shared documents, instant messaging, search, etc.) that they'll want to group together under one heading.  As I've written before, once Google makes this move, it will be essentially the same thing as Yahoo's del.icio.us with the one difference being that Google will undoubtedly AJAXify it's search results so that search users can very easily and contextually apply their taxonomy to one or more entries on a search results page without having to reload any HTML.

When I asked Murray about this obvious next step for Google, he concurred that it all made sense but fell short of confirming that anything like that was in the works.   For the most part during the interview, Murray stuck to issues relating to GMail. But he did say "we are converging in terms of our offerings, [and] the UI affordances....we know that we don't want people to have to reinvent the wheel or learn 20 different types of user interfaces."

Speaking of AJAX, I asked Murray about the rumors that more GMail interface improvements were on the way and he confirmed that in the next couple of weeks, users of GMail should notice better overall performance to the Web interface thanks to a pre-fetching feature thats part of a complete refresh of all of GMail's underlying AJAX engine.

There was no mention of any offline capabilities along the lines of what my fellow blogger Garett Rogers wrote about with respect to going offline with Google Calendar. But, I don't think it's possible that GMail's AJAX engine would go through such a complete rewrite unless it had going offline via Google's offline technology known as Google Gears (the way Google Reader currently does and Calendar will) in mind.  So, my sense is that we should expect that pretty soon and why not? One of the advantages of Web-based solutions like GMail, Salesforce.com, and others is that updates and bug fixes can be rolled out to end users whenever Google wants to.  Unlike with shrink-wrapped software where significant complexity is involved in pushing new code down to local clients, updates and fixes are available immediately to end users of Web-ware the next time they hit the refresh button on their browser.

Murray and I talked about the release cycle and according to him, a new release of GMail is going out almost every week now. Some of the changes (like the addition of IMAP support) are more obvious than others (eg: bug fixes).  According to Murray, Google takes problems with the user interface very seriously (not just in Gmail, but in all of Google's services) and has the equivalent of an emergency response team that, like antibodies, converge on bugs and knock them out pretty quickly.  In a something of testimony to  the advantages of Web-based software over its shrink-wrapped competition, Murray claims that the engineering turn around time to address some bugs has been as little as 15 minutes.

Murray and I covered a lot of other ground as well.  For example I asked him whether or not Google might eventually embrace folders instead of labels in its GMail user interface and he talked about that being a major issue for other GMail users as well (expect some changes there!).   We also talked about APIs and whether Google might be opening Gmail up to developers any time soon.