[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 21 Apr 2011 14:59:12 +0200
On 2011-04-20 at 23:56:10 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
wrote:
> Somehow agree to defer this a bit... More interesting for me is for
> example how to implement the local cache? The local storage should be
> robust against fs crashes, think that is not trivial to implement.
>
> A possible solution would be to abuse a bfs iso image for the mail storage
> (really just to store mails internally), This would also gives easy query
> support. I see some problems with this though:
> - performance does not becomes better
> - query support does not work for pseudo attributes (Mail:thread) or
> dynamic attributes (Mail:account)
> - is it possible to increase a bfs iso?
ATM BFS does not support resizing, so you could resize the image file itself
(it isn't an "ISO", BTW), but that wouldn't help.
> probably its better to store the mails in a raw file and load them
> (filenames and attributes only) into a modified bfs ramfs on startup.
> Proposal for a flat file format: store mail header, internal header and
> body part in separate not necessarily continuous blocks. In this way a
> body can be added at the end of the file without the need to move (and
> potential corrupt) other parts. The internal header could also be modified
> with single fs operations... But how to delete messages?
>
> Did I miss a simple solution? Any ideas?
Regarding the crash safety, there's fsync(), so it is rather simple to make
sure that data are safely on disk.
ATM I don't find it very interesting how the cache is implemented in detail.
I would make sure that it has a simple programming interface, so that the
actual implementation can be replaced without affecting any other parts of
the FS.
Without having given it much thought yet, I would probably start using
individual files for the mails (maybe even for their parts) and an index
storing all the meta data (generated as well as editable attributes). The
index could be something hown grown or could be based on a database solution
(squlite?).
CU, Ingo
Other related posts: