I, like many people on the Internets, was ecstatic at the announcements of IMAP for Gmail and the blogosphere-dubbed "Gmail 2.0". I'm all for a faster Gmail experience, not to mention an implementation of the mail retrieval protocol that was developed at my alma mater. However, my enthusiasm waned in two parts, when I actually tried out these features.
When IMAP was finally enabled on my account, I opened up claws-mail and configured it to use Gmail as its mail source. When it did the mail sync operation, I noticed that it didn't populate the virtual "label" folders properly. By that point, I gave up and did something else. I learned later during my blog reading that Gentoo's flameeyes had the same problem. If you look at the comments, you'll see that Claws-Mails's developers have acknowledged the problem as Google's fault. As a(n annoyed) developer, I would agree with their assessment. As a pragmatic developer, however, I agree with flameeyes's assessment: The Claws-Mails developers should follow Postel's Law.
Part two: trying out "Gmail 2.0". Regardless of how I feel about the blogosphere's echo chamber (and by extension, the mainstream media's echo chamber), I'm using that term for it because it's convenient. Yeah, it's a cop-out. Anyway, this refactoring of Gmail's dynamic JavaScript engine seems to me, to be a step back, in terms of speed (or at least, perceived speed). Sometimes when I change tabs back to Gmail, the message list column is squeezed horizontally, as if I changed my browser window size to 200x900. When I change label views, there tends to be a lapse between unloading the old label's mail and loading the new label's mail. This leaves a big green box in the interim.
I do realize that these features are relatively new, but you'd think user/unit testing would catch these things.
1 comment:
See the third comment on Flameeyes' blog for more info about why Gmail really blows.
Post a Comment