[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:
