[Gllug] OpenChange and SOGo

[Jason Clifford]

On Wed, 2011-02-02 at 08:57 +0000, James Courtier-Dutton wrote:
> I do not like the IMAP protocol.
> It is really slow.
> If you take the typical use case.
> 1) Display to the user the latest 10 email headers in the inbox. I.e.
> From, To, Subject, Date
> All IMAP clients I have seen have to first get the headers of every
> single email in the inbox, and this could be >1000

Most of us have a connection to our imap server which is capable of
getting a few kB of headers fairly quickly. If you find that opening
your inbox takes a very long time that either means the inbox has too
many messages in it and needs to be reorganised or that the server is
either not configured properly or has IO problems.

> 2) Display the next email header, e.g. the 11th.
> Again, the client has had to get all the headers in the inbox, before
> it can navigate around it.

And that's why most clients will grab all headers in a mailbox when it
is first opened so as to have them ready and so not need to do that.
Certainly my MUA doesn't download all the headers just to open a
message.

> The current situation I have is this:
> 1) Cyrus IMAP server holds a copy of every email.
> 2) Thunderbird email client also makes an entire duplicate of every
> email for that user.
> So, twice as much HD space is needed than should be.

But that is only because you decided to set your MUA to retain a local
copy of those messages. The up side is that you have access to the
messages in the event that the server is unavailable and have a simple
backup.

> I want a simple protocol that does the following:
> 4) Be able to cache emails locally at the client, so that they can be
> read offline.

So why are you complaining that the IMAP protocol (which is very simple)
allows you to do just that?

> 5) If one email user decides an email is junk, automatically tag it as
> junk in all other email boxes.

That is not a good idea. Your idea of what is junk may be very different
to someone else. A decent MTA level filtering solution already offers
that facility to determine that a message is spam or infected with a
virus or similarly unwanted content globally. That is the place to make
such a determination. Once you get to the point that messages are in the
message store it's too late.

> Then, the email client can be a lot thinner, and work just as well on
> a mobile device.

I don't think that assumption is true. Why do you think it would be?

You've stated that you want to have local access independent of the
server availability. In that case you need the all of the client to be
implemented locally if you want the local mail cache to actually
function.

--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug