On Thu, 2011-05-19 at 11:42 +0100, Pete Biggs wrote: > I'm sure you know this, but there is no "move" operation in IMAP - so a > move is implemented as a "copy" and "mark as deleted". For what you are > suggesting to work, then you need to end up the sequence with a "purge > folder" so that the deleted message disappears from the folder. It's > this last operation that is problematic in some instances - it's an > expensive process on some servers (i.e. those with large MBOX format > files) - doing a folder purge everytime you press the delete button is > not very friendly.
This is an issue with using the IMAP protocol to implement the 'real trash folder', you are absolutely right. But it's an issue that we have to deal with *wherever* we implement the 'conversion' from flag-setting to message-moving. I haven't looked at exactly how this *is* handled in the IMAP code. Does it actually issue the EXPUNGE, or just rely on the fact that the user is running with the 'hide deleted messages' option set? Either way, this is not a *new* issue. > I understand that the delete behaviour would be configurable - but is > the re-write of Evo internals worth it just so that Exchange users are > not inconvenienced by having to learn a new way of working? I think you misunderstand. This "real trash folder" feature request has been around for a long time; it isn't something that's being suggested purely for the benefit of the EWS back end. I'm just saying that I haven't paid much attention to the deletion handing in EWS yet, because once the 'real trash folder' support is done *generically* in Camel, we should be able to use it. -- dwmw2 _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-list
