[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: Donn Cave <donn@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 14 Apr 2011 08:02:05 -0700 (PDT)
Quoth Anshul Singhle <xashck@xxxxxxxxx>,
> 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?
No! Forget Tracker, for the moment. Your filesystem should support
its essential functions through standard I/O operations on files, so
that applications can work with it. Your user normally needs to
download the full message only the context of some application that
will operate on the data, so in effect it's the application that
needs to download it.
The contents of the file should be the whole message - what you would
get with an unqualified FETCH BODY, which includes all header data,
MIME parts, everything. For the first implementation, you might even
get it that way, but in this way you only defer the question you pose
above - eventually, a satisfactory implementation will need incremental
transfer.
The simplest way to do that, is on demand, to satisfy I/O requests
for file data. A sophisticated application may seek to the beginning
of the 4th MIME part and start reading, causing that part to be fetched
on demand if it isn't cached. A naive client will naturally start at
top; that would of course require the header, and you might decide
it's optimal to bring the first body part along at that point (the
fewer IMAP requests, the better.)
> 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 FS
> will get mails recieved after the last cache-empty event. The user can also
> archive certain mails, so that they remain permanently on his archive(The
> archived 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 from
> the archive after which they behave like normal deleted mails.
Well, it worries me that you seem to want to start off an IMAP client
implementation with the perspective that standard IMAP as designed
"looks like bad news". This is a strong point of Haiku, compared to
other operating systems including BeOS before it - there's such an
visible respect for the external world and the standards and principles
that make it work.
Anyway, the problem I foresee is that mail won't be deleted.
I can't think of a good way to make the IMAPFS work with Haiku Trash,
in the sense of the "mashup" directory as described earlier in this
thread. The Trash metaphor is very natural, but combining with disk
files from other filesystems strains the metaphor to the point where
it isn't useful.
Bear in mind, incidentally, that this also has to work outside of
Tracker - to fully support POSIX remove (unlink, same thing.)
Donn
Other related posts:
