[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: Donn Cave <donn@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 9 Apr 2011 08:15:09 -0700 (PDT)
Quoth "Jonas =?windows-1252?q?Sundstr=F6m?=" <jonas@xxxxxxxxxxx>,
...
> 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.
IMAPFS will be a remote filesystem, I guess maybe the first one
if Haiku doesn't have a widely used NFS implementation. It's going
to work best, in my opinion, if it's allowed to function as such
as far as possible. For example, stat() on the message "file" should
show the remote size, and read() should input the contents of the
file via IMAP network I/O if it isn't already cached. This will
generally take a little more time than disk I/O, but if applications
deal with this poorly, it isn't the filesystem's problem to solve.
What's weird about it is not so much that the data is remote,
but that messages have specific structure - headers etc. -
and are retrieved according to that structure. An incomplete
file in NFS would be trivial, FS network client just reads the
blocks necessary to fulfill whatever I/O requests as they occur,
where the IMAP version is perhaps complicated a little as the
same local read() is satisfied by "structured" network I/O.
But that's manageable, and not a reason we need to complicate
local I/O.
It might be a good idea to lay out, as part of the proposal,
what form "the contents of the file" would take, for a naive
reader that simply opens the file and reads all blocks.
I would assume it's the full everything - full header, empty
line, followed by all parts of the file. Earlier expressed
some concerns about foolishly reading all parts of the file,
including possibly a giant attachment, just to see the first
part, but given the "on demand" implementation per above,
a smart client could avoid transferring the attachment by
simply not reading that part of the "file", aided by seek
offsets that could be stored as attributes - attribute with
offset, size and MIME type of each part. Relying on the
filesystem to transfer data with per part requests where
appropriate, which could be subject to refinement even if
the initial implementation takes the simplest route and
transfers the whole message like POP3.
Donn
Other related posts:
