[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: Donn Cave <donn@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 16 Apr 2011 18:35:43 -0700 (PDT)
Quoth "Ingo Weinhold" <ingo_weinhold@xxxxxx>,
...
> 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.
The thing is, the natural semantics of "delete" for IMAP is the phased
process we've been talking about - first, a per message flag that affects
presentation only, and then a per mailbox expunge that finally obliterates
the message. From that perspective, the expected result of unlink() is
the \Delete flag, and whatever change in presentation goes along with it.
You could just "disappear" the file entry, but moving to a per mailbox
trash folder in the filesystem is more deluxe.
Trying to match the semantics of BFS etc. on this point is bound to
make a poor IMAP client implementation, and I feel it will be for little
gain - no one will really appreciate that consistency.
> 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.
That's interesting, I guess we need to take into account how email
accounts really work out there even if practices more or less depart
from what you'd expect from reading the IMAP protocol RFCs. I have
already acquired a gmail account just to see their queer practices
for myself, but am not in a hurry to do the same with GMX. I doubt
there is any possible IMAPFS implementation that can manage to work
consistently across the full range of possibilities, but it's interesting
to think about what will break.
I think if IMAPFS implements a Trash feature, it is going to have to
be independent of these external Trash mailboxes. IMAPFS-Trash is for
when "the message in the associated mailbox has a \Delete flag."
If GMX transfers the message to GMX-Trash when you apply the flag,
then it will not appear in IMAPFS-Trash but will appear in GMX-Trash
(without any previously cached data, since for all we know it appears
to be a new message.) If GMX copies the message to GMX-Trash, it
will appear in both.
Donn
Other related posts:
