[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 17 Apr 2011 00:11:22 +0200

On Sat, 16 Apr 2011 23:15:36 +0530 Anshul Singhle <xashck@xxxxxxxxx> wrote:
> >How should you present a message that has the \Delete flag?  Today,
> >my opinion is that you should simply ignore the message - from the
> >filesystem, it would appear to be not there.  No Trash folder.
> >Some email applications - probably many - do it that way.  It's
> >simple and effective.  I personally like to have more explicit
> >control over the flag/expunge process, but I'm not really a typical
> >IMAP user.  If users turn out to be really interested in this point,
> >some suitable feature can be added to IMAPFS later.
> Here is where the local Trash folder comes in. The messages that are
> deleted
> are moved to the Volume's Trash folder. Empty trash means EXPUNGE. User's
> can undelete mails from their Trash folder. Note that this folder is
> per-volume and not haiku's trash folder

Please try to use a consistent nomenclature to avoid misunderstandings in the 
discussion. "Deleting" an entry means removing it permanently 
(unlink()/rmdir()). For file systems with a trash folder trashing an entry 
(moving it to the trash) is an ordinary move operation (rename()). Whether IMAP 
FS has to implement special semantics for a move from/to the trash directory 
probably depends on the settings.

> Based on your comments i feel its best to leave the server out of this.
> i.e.
> simply mark as \Deleted on the server. AFAIK, the server has mechanisms to
> handle deleted mail. Its best to leave this option configurable due to the
> way different clients handle this.

The natural behavior is:
* A "delete" operation removes the mail permanently from the local file system 
and from the server. Regardless of whether it was in the trash or not.
* A "trash" operation makes the mail disappear from the local folder and appear 
in the local trash. It also makes the mail disappear from the respective server 
mailbox and appear in the server's dedicated trash mailbox. If the server does 
not have such a mailbox, trashing cannot be supported and trying to trash 
should prompt the user whether the mail should be deleted permanently instead.
* A "restore from trash" operation makes the mail disappear from the local 
trash and reappear in the folder it originally came from. On the server the 
mail will reappear in the respective mailbox as well and disappear from the 
trash mailbox.

This is the expected perceived behavior. How IMAP FS achieves that partially 
depends on how the server works exactly, which the user might need to specify 
via settings. E.g. my GMX mail account sports a trash mailbox, whose name I 
should need to specify when setting up the IMAP account info in Haiku. The 
server automatically deletes mails moved to that mailbox after a configurable 
delay, i.e. I would expect that after trashing the mail in Haiku, it will 
automatically disappear from trash after the delay has elapsed.

> See
> http://mail.google.com/support/bin/answer.py?answer=78892

From that I can't say I fully understand how google's IMAP implementation 
behaves. It might need some experimentation to get the expected Haiku behavior. 
Particularly the feature that a mail can be in different mailboxes might be 
tricky to map (locally it's just hardlinks, but the trashing part might be 
"interesting" (in the Pratchettesque sense)).

CU, Ingo

Other related posts: