Amplexos. (btw: I used some non-breaking spaces entities to format the paragraphs. in the live preview they look ok, but I don’t know how they’ll look like in the final version, so I’m sorry if they appear as the horrible-looking entities).

Even if we consider that there exists no atomic move command (you see, I’ve written my blog entry not for a IMAP developer, but for a user of Mail.app, so I was not exactly detailed), what do you think is more efficient considering you want to delete a mail message with a 10 MB attachement and further considering you are behind an analog connection:

1) Do it locally:
- Download the Message (10 MB downloaded - takes ages)
- Mark Message as deleted
- Remove marked message
- Upload the Message to the trash folder (10 MB uploaded)

2) Do it on the server
- Copy message to trash folder
- Mark original as deleted
- Remove marked message

Now tell me what’s faster: Loading 20 MB of data over a analog connection or just moving around 20 MB on the server?

That was my point. Not semantics or protocol details.

Philip

thanks for referring to my blog. Unfortunately, as I have changed the engine, the old links are not valid any more. If you want to read the posting, maybe consider visiting its new location.

Philip

Using new technology in communication isn’ the same as in other areas. Interoperability is essential. It does me no good to switch to some great new mail protocol if I can’t find an ISP that will provide me with access via that protocol (and assuming that I don’t want to run my own mail server).

There are plenty of good reasons one might use an inferior technology when a superior one is available, but it is (IMHO) almost never worthwhile to limit yourself to an inferior technology simply because the superior technology might not take off. Even if the path you choose does eventually die, so what? You’ve spent a few years being less frustrated and more productive than everyone else, and that’s worth something.

Not only that, but you then have to convince ISPs (etc) to provide additional servers. Unless there’s a clear benefit to them, or huge numbers of users are demanding it, that’s unlikely to happen, IMO.

Tony, I think you’re being too harsh on IMAP, and I think you are mistaken.

I develop with IMAP nearly every day, and have done for years now. I am not too harsh at all, and I certainly am not mistaken.

You should take a look at commands like APPEND (6.3.11), COPY (6.4.7), and EXPUNGE (6.4.3) command.

I have read the RFC many, many, times. EXPUNGE (like CLOSE) permanently removes messages marked as \Deleted, returning information about which messages those were (CLOSE doesn’t do this part). That’s it. COPY copies a message, leaving the original alone (i.e. it’s a copy, not a move). APPEND adds a new message, it has nothing to do with moving.

As you can see, there are a number of ways to “move” messages on the server.

Actually, no, there are no ways. You can only create a new message (either reading and writing with FETCH and APPEND, or more efficiently via COPY) and delete the old one.

However, this is all done at the server level using highly efficient algorithms that work directly on the disk.

Well, how efficient things are depends on how well the server is written, obviously. This is a silly thing to say.

IMAP commands (even including searching and selecting messages) should be done on the server where there is fast access to the mail.

I don’t know what you mean by “selecting” a message. There are too many variables involved to know whether searching would be faster with a local cache or on the server.

It’s actually even worse, because you can’t delete an individual message. You can mark messages with the \Deleted flag, but to actually remove the message you have to purge all the \Deleted messages in the folder.

I’m not quite sure how this is “worse.” Like you say, the alternative is to move messages into a “Trash” folder (which still is available on IMAP).

This is worse because it is not possible for an IMAP client to delete an individual message (well, unless you check which messages are \Deleted, change that, \Delete your message, expunge, then restore the flags of the other messages, and have some way of being sure that no-one else is changing the flags at the same time). Deleting an individual message is a useful operation when writing IMAP clients, particularly when moving or altering messages.

IMAPv4r1 is very versatile.

IMAP tries to be too versatile. It allows too much flexibility in how the protocol can be implemented, which means that coding for it is overly complex. Despite this, it lacks the ability to do many desirable tasks (alter a message, delete an individual message, move a message). There’s insufficient room here to go into all of IMAP’s flaws.

It is designed SPECIFICALLY to address all of your concerns

Actually, Crispin didn’t have any of my concerns in mind…

I think if you really sit down and think about it, all of the things you list as limitation of IMAP are just different ways of doing things.

No, they are limitations. Trust me, I work with IMAP server and client code nearly every day, I have “sat down and thought about it” many times.

I think this is taking too much space for comments, so if you want to debate this further, I can blog about this myself and leave Tim’s space alone.

And thanks to Tony for explaining the lack of an atomic move operation and other IMAP protocol deficiencies. I remember discussions about those particular issues on Mulberry’s mailing list.

Anyone (e.g. Tony :-)) aware of alternatives to the IMAP protocol being proposed? My at-a-distance impression is that the IETF has been more interested in things like moving certain IMAP extensions out of draft stagnation than in coming up with a better protocol to replace it. In other words, it seems the hope and effort is still to “save” IMAP more than eventually abandon it in favor of something superior.

This guy clearly doesn’t know what he is talking about: there is no “IMAP move command” (this is simple to verify - just search through the RFC for “move”, and you won’t find anything). This is one of the major flaws in the IMAP protocol - the only way to move a message to another folder is to create a copy of the message in the destination folder, and then delete the original.

This is the document to which you are referring:

IETF RFC 2060

You should take a look at commands like APPEND (6.3.11), COPY (6.4.7), and EXPUNGE (6.4.3) command.

It actually is a little more helpful to view the man page of the mailutil command:

mailutil.1

As you can see, there are a number of ways to “move” messages on the server. It’s true that these methods are not “atomic” in that they copy messages, mark the old ones as deleted, and then expunge them. However, this is all done at the server level using highly efficient algorithms that work directly on the disk. It’s much better than having to shuffle messages off of the server and then back on.

So I *THINK* you’re getting tied up in some semantics issues. Regardless, I’m sure you see the point of the original poster: IMAP commands (even including searching and selecting messages) should be done on the server where there is fast access to the mail.

It’s actually even worse, because you can’t delete an individual message. You can mark messages with the \Deleted flag, but to actually remove the message you have to purge all the \Deleted messages in the folder.

I’m not quite sure how this is “worse.” Like you say, the alternative is to move messages into a “Trash” folder (which still is available on IMAP).

IMAPv4r1 is very versatile. It is designed SPECIFICALLY to address all of your concerns while also providing lots of neat ways to handle mail while ALSO storing it in a central location on the server.

I think if you really sit down and think about it, all of the things you list as limitation of IMAP are just different ways of doing things. Personally, I’m happier with doing things a little differently because I pick up the added performance of IMAP as well as the ability to manage my mail in one place at one time and share that management everywhere.

Additionally, most modern IMAP clients are designed to allow you to use IMAP just like POP… So you don’t even notice that you’re doing things “differently.” This is the flexibility of the IMAPv4r1 protocol. It’s really meant to be an API to allow a mail client to transparently implement an efficient server-based mail system.