Alex Hudson

Thoughts on Technology, Product, & Strategy

Tag: imap

An argument against the “fat client”

This is based on Miguel’s desire for an IMAP interface to his Evolution mail, but isn’t really focussed on that particularly problem: rather, the more general problem of where “collaboration brains” belongs. One of the things which I think seems to be a bit worrying about free software mail clients is that there is this continuing move to smarter and smarter MUAs.

Miguel is actually asking for something which is much closer to what KDE are doing: the Akonadi project, as I understand it, is basically almost a full-blown local groupware/collaboration server. It uses a private MySQL instance, and has everything “built in” to this middleware which can sit on top of existing mail / contacts / etc. stores.

This also came up in the discussion the other day about Thunderbird 3 too – in order to do the “great local search” thing that they want to do, they basically have to download an awful lot of information about mails and keep it around. And again, you end up with effectively this local cache of remote information, and a local “groupware” thing.

I really don’t like any of these approaches. For me, the brains belongs in one place: on the server. There are a whole tonne of good reasons for this – not least locality to the data and keeping the client simple – but it also seems to me that the main drivers for these fat clients are only feature requirements, not technical requirements (I absolve offline access of this – that’s a technical requirement).

The main problem with the fat client approach is that you get data loss, like Miguel suffers: if something gets entered into the client and doesn’t make it to the server, it doesn’t make it to other clients. If you use a desktop app and a web app, you have to suffer through not having your up-to-date address book, or not having your “junk” status flags, or different filing rules, etc. etc.

Of course, this isn’t really a client problem per se – it’s a server problem, because we don’t have the protocols and the ability right now to let clients do this “the right way”. People have tried using stuff like IMAP and it kind of works, but it’s a hack. But by working on the client side, it just exacerbates the server problem. I’m sure people who’ve moved from Evolution to Thunderbird, or who use an IMAP client which has one way of deleting items with another client which does things the other way, will know what I’m talking about.

It’s difficult to know what to do about this, though. Working on Bongo is one answer, because better servers will encourage more lightweight and featureful clients. Being able to access the same information from Evo/Tbird and from Bongo web UI is an absolutely crucial use-case. But it will take time, sadly…

Thunderbird 3

Unlike Jono, whose experiences with Tbird 3 are worth a read, I’ve been a loyal Thunderbird user for a few years now – in fact, we’ve had it deployed at work relatively happily for a while now (I say relatively – the mail client is fine; lack of calendaring is a bit of an issue…). I also tried the Tbird 3 beta recently too, although I think I met with even less success.

For one thing, I was trying this out on the EeePC 901 I have, and for whatever reason, they really didn’t get on at all. I could log into my Bongo mail ok, but the mail box was entirely read-only: no marking read, no moving, no deleting. And the GUI problems just got worse from there – functions which should have been there were just completely missing. I suspect this is to do with either the distro or something I have in my environment; speaking to others, they had much more success, so I plan to try it again in the future.

I also see Tbird as a project with an enormous potential. However, the appearance of Tbird 3 really surprised me, and David Ascher’s blog post on the direction wasn’t something which filled me with a huge amount of confidence. I don’t get some of this at all; a great example is tabs. I just don’t see the value. I can see people lining up mail messages to respond to and that kind of thing, but that seems a really poor UI to my mind. Another example would be the complete Gmail-like effect in the screenshots in that blog: it’s basically Gmail offline, which is fine if that’s what you want, but.. eh.

As a server guy, the “improved search” stuff also worries me. It looks very much like client-side searching, which is fine for personal mailboxes. Once you have a few shared boxes and bigger corporate-level stuff, that starts to become a bad plan very quickly. But it seems to me that the business market is really where Tbird should be aiming: people at home are pretty happy with Gmail and stuff already. I don’t see why they’d want to access Gmail over IMAP.

It will be interesting to see how Tbird 3 turns out. Integrated calendar is absolutely crucial. Hopefully it can all be pulled off without becoming a less business-suitable product. Mozilla Messaging have the resources, but they seem to be trying to take on a lot with this first bite.