Am 08.04.2011 09:53, schrieb Anshul Singhle:
Thanks for the feedback :) 1. About deletion of mails : How about this - User presses delete key/deletes it in any way, the file is moved to the Server's Trash folder *and* flagged as /Deleted. When the user wants to empty his trash all the "deleted" mails are removed from the server i.e. Empty Trash. Regarding storage on Filesystem, same behavior - moved to a trash folder which can be emptied. The Trash on server and on FS will remained synchronised i.e. If you empty server trash, FS trash will empty and vice versa. I'll have a look on implementation and update my proposal ASAP provided this is satisfactory.
Perhaps there is still some confusion. There are three simple features involved:
1) The IMAP FS needs to support the regular "remove" operation on file entries. How this is implemented does not matter, as long as the result of this operation is that the email is gone from the server. This operation is not supposed to be revertable.
2) The IMAP FS needs to support moving a file entry from one directory to another directory.
3) The IMAP FS needs to expose the server's Trash folder (note that it may be named differently) as "trash" folder at it's root directory and it shall not display it under its real name (like "deleted mail" or whatever).
When all these three features are implemented as I described above, moving mails to the Trash via Tracker will already fully work. Permantly deleting mail via shift-delete and emptying the Trash will also automatically work. You do not need to implement any extra logic as long as these three things above work:
When the user presses the delete key on an IMAP FS e-mail file in Tracker, Tracker will use feature 2) to move the mail to the trash folder exposed by feature 3). This will have the expected effect on the server, if the IMAP FS handles this move operation by moving the mail to whatever is the dedicated trash folder on the server. Using the Tracker to open the Trash on the Desktop will merge the contents the Trash folders of all mounted volumes, including the ones from the IMAP FS accounts. To restore the mail to its previous location, Tracker uses feature 2) again to move it into the original folder. The original folder is remembered via an attribute on the file which Tracker writes when moving a file to the Trash. For this to work, IMAP FS would have to support storing arbitrary attributes. Even if writing custom attributes and thus the "Restore" mechanism is not supported, the user could still drag the mail into it's original location, again using feature 2).
As already said, I do not know what the /Deleted flag is good for. Maybe it can be used for an "undelete" feature, but like I've already said, the displaying of mails with /Deleted flag is completely up to the client and the implementations I've seen so far are useless and I really would rather have the mail permanently removed by feature 1).
2. Queries : My intention was to support the already existing haiku query. To allow haiku queries to query files on a remote IMAP server would require extending haiku query(right?).
Not that I am aware of. At the moment queries are completely implemented inside the file system, so you can handle them whatever way fits.
Best regards, -Stephan
