On Thu, 14 Apr 2011 23:40:46 +1200, Anshul Singhle <xashck@xxxxxxxxx> wrote:
Hi, first of all to reply to all the other mails in the thread, please do not make stuff more complicated as it is! There is a working IMAP lib now, please just use it and focus on putting it into a FS. You can probably do nice stuff by downloading just some mime parts of the mail but I can imagine that this alone would take significant time of GSoC!
There is enough work to do any way:- create a storage (a DB) to store the partial or complete messages persistently - connect the storage to the fs (mount, read -> just read the files in the database, attributes)
- ioctrl interface to communicate with the fs - log and error report to client listener - query support - sync mailboxes on mount - watch the mailbox (IDLE) - multiple mailboxes of one account - move mails between mailboxes - trash folder - APPEND mails (if time left) - ... All of the IMAP parts are working in the current lib!
I'm working on a revamped proposal and I have a few queries :
1. One of the essential features is downloading mail headers only. I need
some advice on how this would work. Consider the following:
Mail header is downloaded as a file with attributes as usual, but the
file contains only the Sender , The subject and the date. the natural
question now is how would the user ask for the full message to be
downloaded? Will a tracker-addon be sufficient? so that you simply
right-click the message and you get an option to download the whole
message?
just as it is working at the moment. The client trigger the complete message download (using an ioctrl) and get notified when it is done then the client just read the cached message from the fs. As proposed later trigger the download in a read operation is a very, very bad idea because this blocks the reader till the message is downloaded! waiting for a quick cat till 10mb attachment is downloaded seems horrible to me ;)
2. Query support : I want the emails to be query-able in much the same way they are now? Does adding query support require anything special? AFAIK, if I make all the query-able entities file attrbutes then queries should work.Is that right?
Not sure how to reuse existing code but the theory is to parse the query apply it to the IMAP fs case and return the results.
3. Cacheing : the big question is - how much mailbox data should we save on disk? Currently atleast the headers of every mail that has not been deleted will be saved. Of course the user can be given options so that mails beforea particular time are not stored on disk. I read some discussions on the topic of mails and discovered that some users want the Filesystem to be avirtual reflection of their IMAP accounts. The question now is when shouldthe mails be retrieved?
Don't bother about this at the moment. Just store everything that is downloaded for now. Quick and dirty solution: If the user really run out of local disk space (unlikely IMHO) he has to delete the account and recreate it. The headers are the bare minimum.
4. Deletion : Based on how Gmail and other clients such as Thunderbird work,the /Deleted flag looks like bad news. So this is how I propose deletion should work- When the user deletes a mail, it is moved to trash folder on his FS as well as his server. To remove the mail completely, goto your trash folder and delete the mail from there, it will be removed from your computer as well as the server. If a user wants to empty the cache on his computer, he can do so. The FSwill get mails recieved after the last cache-empty event. The user can alsoarchive certain mails, so that they remain permanently on his archive(Thearchived mails are not touched on the server, they only stored in a seperate folder on the user's computer) until of course the users deletes them fromthe archive after which they behave like normal deleted mails.
The \Delete flag should be used in any case because other clients are using it.
cheers,
Clemens
