[haiku-commits] Re: r40736 - in haiku/trunk/src/add-ons/mail_daemon/inbound_protocols/imap: . imap_lib

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 28 Feb 2011 10:43:48 +0100

On 28.02.2011 09:27, clemens.zeidler@xxxxxxxxxxxxxx wrote:

Author: czeidler
Date: 2011-02-28 09:27:23 +0100 (Mon, 28 Feb 2011)
New Revision: 40736
Changeset: http://dev.haiku-os.org/changeset/40736

Modified:
    
haiku/trunk/src/add-ons/mail_daemon/inbound_protocols/imap/IMAPInboundProtocol.cpp
    
haiku/trunk/src/add-ons/mail_daemon/inbound_protocols/imap/imap_lib/IMAPHandler.cpp
    
haiku/trunk/src/add-ons/mail_daemon/inbound_protocols/imap/imap_lib/IMAPHandler.h
    
haiku/trunk/src/add-ons/mail_daemon/inbound_protocols/imap/imap_lib/IMAPMailbox.cpp
    
haiku/trunk/src/add-ons/mail_daemon/inbound_protocols/imap/imap_lib/IMAPMailbox.h
Log:
google expunge all deleted flagged messages automatically but some server keep 
them and EXPUNGE has to be executed explicit. Add the infrastructure for 
expunge but don't use it for now. The problem is that with each expunge all 
messages are deleted and calling expunge each time when a mail is deleted would 
delete messages in a virtual trash folder on other clients. Have to think about 
how to deal with it first. So it might be that you delete a message and the 
message will be downloaded again when you sync the next time (but the message 
is flagged as deleted).
In one of the tickets I've already written it, I think the whole approach with mail_daemon, Mail and Tracker for managing mails can only work when IMAP is implemented as a file system. Then you can delete mails from Tracker, which will put them into the Trash folder of the file system, and effectively into the Trash folder on the IMAP server. How could anything else be made to work reliably in all situations? And now that we have bindfs, we can mount the IMAP folders into /boot/home/mail/<account name>. 

Best regards,
-Stephan

Other related posts:

  1. Home
  2. haiku-commits
  3. Archive
  4. 02-2011