[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
- To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
- Date: Sat, 09 Apr 2011 17:57:57 +0200
Anshul Singhle <xashck@xxxxxxxxx> wrote:
> @ Jonas There is still one question, about the cache storing mails
> as they are on the server and the Volume displaying something
> different to the user?
> Is it really necessary to do this?
(Strictly speaking you don't need to cache, but it is a good idea to
have one so you can work offline, and so you don't have to connect
directly at system bootup, or whenever you mount.)
> If you store mails the way you view them i.e. The deleted mails
> are actually moved to a Trash folder, will that cause any problems?
You are free to do the caching storage any way you like, but there
will be a difference which you have to deal with, (unless you suppress
the use of a trash folder) either between the view in Tracker and
the cache, or between the cache and the server.
...
> >But I think it would be better for the user experience to have
> >the imap-fs provide enough information for Mail to first open the
> >partial mail, unequivocally decide that it is partial, and then
> >be able to offer the user the -choice- to download the full message,
> >if the user hasn't already configured Mail to do so.
>
> If the user has configured for this option, only headers will be
> retrieved first. They will be stored in a file containing only
> cursory info such as the sender, subject,date. The user can then
> completely download the mail, at which point this file will be
> emptied(not deleted) and the contents replaced with contents of
> the mail. How will the user trigger this? I'm still not sure,
> adding a menu in Tracker seems simple enough so we'll go with that
> initially.
Haiku has a concept called node monitoring, by which apps can
subscribe to changes on a file or a folder. (Not having to poll.)
So Mail could ask for the full message to be downloaded (I think
an ioctl could be used to ask the filesystem for it.) and then wait
for the full mail to be updated. (I suppose an attribute could be
used to signal error to Mail, so it doesn't wait eternally.)
Since the fs likely does the content updating itself, it would
have to generate the node monitoring events itself.
I think it would be beneficial to have the cursory info stay close
to the rfc822 format, but I guess it's not a strict necessity.
Attributes can be used for IMAP extras, like a message's unique
identifier and the uid-validity value. So you don't need to stuff
all that in the file itself.
> >To have Mail block on reading would be a bit crude, and it would
> >necessiate always showing some initial visual feedback at launch
> >or after some short timeout, (e.g a barberpole and a message)
> >which would be meaningless in the non-partial case, let alone mail
> >received by e.g. POP3.
> Now things are getting complicated. :)
No worries. That's not so complicated.
/Jonas
Other related posts:
