[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: Anshul Singhle <xashck@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 16 Apr 2011 20:19:48 +0530
Some remaining doubts :
1. Multipart messages - Previous suggestion have stated that multipart
messages should be stored in a single file, only the header will be
retrieved first. If the user wants to read the mail file at some position,
that part is retrieved. However, one major issue with this is that users
generally read data one file at a time. So, if the user reads a multipart
message (using a text editor or cat) the whole message is retrieved, which
defeats the purpose of fetching one part at a time. The advantage of this
approach is that applications can utilize this feature. A mail reader can
read only a specific portion from a mail file and thus be efficient. Another
approach is saving each part as a separate file, which makes it intuitive
for the user, and applications can also work with this wthout much hassle.
However, the major problem is that too many files will be created and it is
also difficult to enforce file relationships. i.e. Two files which are
different parts of the same message need to be grouped together , aside from
naming conventions I can't think of a way to do this. Putting related files
in a seperate folder also is problematic since there is a one-one relation
between IMAP folders and directories on the Filesystem. So which approach is
better in your opinion?
2. Deletion : Problem arises due to the way different clients handle
deletion. There is a /Delete Flag in IMAP, but GMail doesn't use it. To
remove a file from a server, you need to mark is as /Delete and then
Expunge. AFAIK, there is no other way to remove a file from an IMAP server.
If you run an EXPUNGE everytime a file is deleted, the user could loose some
files i.e. The files he deleted before he started using IMAPFS. The best
solution seems to be : mark as /Delete *and* move to trash folder. That way,
the user doesn't loose any data and also clients with buggy implementation
of /Delete don't interfere with your normal mails. The user can EXPUNGE when
he wishes. Thoughts on this?
Other related posts:
