This is a bity long, so sorry... > The latter solution is an abomination. We've been there, > done that, and got the T-shirt with feedback on > each message. The result was the all-or-nothing requirement.
Been there, done it, using it, fancying it. Still like it. And all-or-nothing requirement never caused me any headache. > MOVE is even worse than COPY in this respect in that it is > not undoable. There is no way to revert things to the original > state with a MOVE that partially succeeded (think about it carefully). Which is the reason why you should be able to call MOVE with one message per request. In fact, exectly, as we've implemented it. Just loop over messages, that's it. That simple. By the way, the same applies to EXPUNGE command - it might fail in the middle, yet nobody complains about it. And think carefully, it cannot be undo to the original state, since other clients were already informed about first messages being deleted! Mark, seriously, it looks like you do not like the idea just because you do not see the reason to use it. Many, many, many, many people use it/miss it, so I think that merits some attention. Of course, you can say, IMAP is not the GUI, GUI should be smart enough etc. But my concern is not with the GUI, but efficiency. There are stores that support it, and for them it would be good to be able to support it in protocol. > Folks, creeping featurism is not a good thing. > It is especially not a good thing when the end > user function is already possible with the > existing functionality set, and the proposed new > feature is a minor tweak that may be more efficient > on some servers. Yes, that's the point. Let's program with assembler, C is just an overlay and is therefore not required. And it really can be proven, since every program in C can be translated to assembler ;-( Just a minor tweak, sort to say. The way IMAP protocol is developed makes it not an attractive solution to big providers. Just looks like the protocol is suitable for only small to medium sized implementations (below, let us say, 100 000 users, and that already with a lot of constraints). But then there is group of companies (mostly providers), who have much more users. If they tried to open IMAP ports to the public, they would just stop working, due to protocol inefficeincies, for example: 1. IMAP does not advertize arrival of new messages. So many discussions on this list, no results. Obvious result: Microsoft/Netscape provides its own solution, and everyone here complains that it is very bad idea to open so many connections to every single folder. "So let's change protocol!" -> "No way! IMAP is not for that! IMAP allows to do it without opening multiple connections, so there is no need!" Final result: people find out that OE does not work well with the IMAP servers, so they often switch to Microsoft Exchange. Not the small users, they don't even realize that they are using IMAP instead of POP3 - but the hard users. And that's a pity, because IMAP protocol - from the RFC - looks like designed exactly for them. Freedom to move, freedom to search your letters, single server with good admin and you are safe. Just a bit slow, but that's the protocol's fault, not ours... 2. MOVE. Looks to me like I already know how it will end up. I do not see any reason that it could not be an extension. But no, it is all or nothing solution, so it is bad. As if programmers couldn't loop over the set of messages and issue several MOVE commands. If you think how MOST today's clients work (be it real client of webmail client), they all support Trash mechanism. So luckily these days the basic paradigm of work with mail is not: deliver/read/expunge, but rather deliver/read/move_to_trash/expunge. And IMAP does not have it. And I miss it. And just the last letter from Mark: "Oh, so now you want a single-message expunge." Of course, I would like, althrough I did not ask for it. Then I wouldn't complain that much about lack of MOVE. How can I move few messages out of the directory, and yet leave some marked as \Deleted behind? Current implementation does not permit it. So we should isolate this view from the user - let us put the GUI in front, which will fake the user and present him what he/she really wants to see. But then, wait, not so long ago there was common complain on this list about caching and statefull clients. They are bad, in short, and therefore should be banned. So now it looks like the two things don't mix well - either you remember your local state on client and hide the server view - and then the whole good stuff about IMAP and it's server-centric point of view is wasted, or you depend on your server-view - but how then can I remember, which messages were moved, and which actually marked for deletion with \Deleted? Of course I can imagine possible solution - just mark the "moved" messages with yet another flag. But that still does not allow me to expunge just them - I should rather mark deleted messages in given mailbox with different flags, then expunge moved ones, since they have \Deleted flag, and then revert back the flags for those, which are really deleted and waiting for purging with real user intervention. This creates so much unnecesary overhead, and is client-to-client incompatible - it will work only with my client, all other will show just flagged messages. Not to mention quota problems, this is where they will immediately appear. And I do not want to "work out" weird solutions, since protocol allows it. A want to have basic features already in standard. The whole idea about IMAP is its server - you do it once, everybody can see it. How do you imagine solution with serveral secretaries working on shared folder, where each of them uses different client, and they are supposed to move appropriate letters to different folders, for further processing? No way, unless the PROTOCOL supports it. But it does not, so they do what they do - each of them copies messages to real folders, and at the evening one of them purges whole inbox, since it is so big, and if the other did a mistake, it is gone. With MOVE, the problem wouldn't even appear. I would love IMAP to support such model of work - for the group work is "advertized" in IMAP, but just that two problems (move and notification) make it very difficult to implement - so people waste thousands of dollars to buy Lotus Notes, i-Planet or Microsoft Exchange, which are much more powerfull, buth then usually they do not need all that stuff, it just works a bit better. Ugh, sorry for the lenghty letter. I realize many people do not agree with me, so I do not expect much to change anyway. Just after 1.5 year of active reading of this list it came out to me that there were many good ideas posted here and yet somehow they were put aside. To keep protocol pure. And, folks, too often I heard here the argument: if you do not like it, switch to something else. I do not want to switch. I want to extend a bit and have a good working solution, with possible efficient implementation. Cheers, Marek.
