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

  • From: Truls Becken <truls.becken@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 9 Apr 2011 11:24:56 +0200

On Sat, Apr 9, 2011 at 05:41, Anshul Singhle wrote:

> To summarize the discussion on Deletion, as I understand it, if user
> "deletes" file on filesystem, here's what could happen:
> 1. On the local machine -
>     1.1 Removal from filesystem
>     1.2 Moving to a seperate folder (defined for each Volume)

Without a local representation there is no way to undelete, so this
depends on choices below.

> 2. On the remote server -
>      2.1 Mark as Deleted
>      2.2 Move to a seperate Folder <warning :) >
>      2.3 Both

I think mark as Deleted, and optionally also move to a specified
folder (which should not be visible locally). The moving is to
co-operate with some other client, and means loosing information about
where to restore the mail, so the user must drag it to the desired
folder himself to restore. (IMAP FS could preserve this info, but not
if the delete happened from another client, so maybe it's more
consistent not to.)

> 3. When do you want EXPUNGE?
>      3.1 Everytime I delete a mail <warning :) >
>      3.2 After every <x> mails are deleted
>      3.3 Only on unmounting
>      3.4 Only when I say so.
>
> We could give the above options to the user.

With 3.1 through 3.3, you get different levels of not being able to
undelete. With 3.1, you obviously don't need 1.2 nor 2.2. I think it
would be best to treat 3.2 as an optimisation of 3.1, and not let the
user see that the mail still exists. Perhaps this should imply
expunging on unmount? One could also imagine using a timeout. 3.3
means that the user needs to be aware that deleted mails are only
undeletable for the duration of his session. Or until the FS is
unmounted for some arbitrary reason.

The options could be presented as:

1) Delete immediately, with an expert setting for the expunge delay.
2) Move to Trash, with an option to empty Trash when ending the session.

> The problem arises in implementing 3.4. If we add a new Item in the menu
> for the mail_daemon(the context menu of the mailbox icon of the Mail Services
> in the Deskbar tray), i guess that should be enough.

Yes, unless you need one per account? A more elegant way would be to
have Empty Trash on right-click of the volume's Trash folder, but that
requires support from Tracker.

-Truls

Other related posts: