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

  • From: Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 15 Apr 2011 19:59:03 +1200

On Fri, 15 Apr 2011 19:21:32 +1200, Stephan Aßmus <superstippi@xxxxxx> wrote:


Am 14.04.2011 23:28, schrieb Clemens:
On Thu, 14 Apr 2011 23:40:46 +1200, 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?

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 ;)

I don't understand at all how the ioctl is any better. The imposed delay until the message can be shown is obviously the same. So it must be no different than blocking the read request until the data is there. The difference is that your ioctl idea forces applications to know about the true nature of the IMAP FS and in fact even know the extended ioctl interface to even read messages. That seems horrible to me. Instead, I would like clients to deal with slow media. I see no difference in Mail for example displaying a barber pole when it encounters a partial mail and has posted an ioctl, or it simply loading the mail data in a separate I/O thread and watching the results of this operation and displaying a barber pole again if it takes too long. That seems robust to me and in comparison the ioctl solution is pretty fragile and unusable in other cases where the same behavior is wanted.

You got me totally wrong ;-) The way it works at the moment is that Mail sends a async body request to the mail_daemon when mail_daemon is done it send a notification to Mail. In case Mail is still waiting for this particular mail it loads the message. Thus, ioctl <-> "async request", no need for a I/O thread.

You also have to handle the case that you can close Mail or go to the next message before the last message is downloaded. This makes everything a bit more complicated...

is there a way to cancel a read()? how would you handle it? (just curious)

cheers,
        Clemens

Other related posts: