Re: [Evolution-hackers] Moving from the single mbox file format for the local folders

[Srinivasa Ragavan <sragavan gnome org>]

On Wed, Dec 16, 2009 at 5:48 PM, Patrick Ohly <patrick ohly gmx de> wrote:
> On Wed, 2009-12-16 at 16:54 +0530, Srinivasa Ragavan wrote:
>> On Wed, Dec 16, 2009 at 4:46 PM, Patrick Ohly <patrick ohly gmx de> wrote:
>> > On Wed, 2009-12-16 at 09:19 +0530, Chenthill wrote:
>> >> On Tue, 2009-12-15 at 15:09 -0500, Reid Thompson wrote:
>> >> > On Wed, 2009-12-16 at 01:16 +0530, Chenthill wrote:
>> >> > > * Not able to create subfolders under INBOX -
>> >> > > https://bugzilla.gnome.org/show_bug.cgi?id=536240 .
>> >> > I hadn't noticed the above, so I guess it's a non-issue for me
>> >> >
>> >> > What is the second issue?
>> >> Sorry missed to mention it here, with maildir we would need to rename
>> >> files for unread/read flag changes which can be avoided in the later
>> >> approach.
>> >
>> > So you expect renaming a file to be slower than rewriting the whole file
>> > content? Somehow my gut feeling says that it will be the other way
>> > around. But I don't have hard data, of course.
>>
>> I fell it will be slower compared to the other approach. You dont
>> rewrite the file entirely at all in normal usage.
>
> Setting mail flags was mentioned as the reason for not using maildir.
> Adding a mail flag to an mbox mail requires rewriting the whole file. Or
> do you assume that you can overwrite just some bytes in an existing mail
> header?
>
> That will still lead to writing a complete sector to disk, in contrast
> to renaming a file which I expect to be implemented more intelligently
> by the file system. Actually, writing a micro-benchmark for this is
> doable. Before you seriously consider investing effort into this, I'd
> really prefer to see some hard data for a "rename vs. rewrite"
> comparison.
>

Maildir is good, none denies it. But maildir is already there, but not
sure how many use it. I remember multiple problems, some subdirs,
windows support etc. Milan did an analysis, some time back, dont
remember that very well tbh.

>> May be when you
>> expunge folder or export it, the summary data could be updated with
>> the mail's mbox. But its debatable at some level, I would say.
>
> We are debating the merits of the actual mail storage, not the summary
> data. I have wiped out folders.db often enough that I won't use
> Evolution when it switches to storing valuable, unrecoverable
> information like the "mail was read" flag there.

Cool. Its about when you write and how you schedule it. In current
mbox design, expunge, rewrites the flags back to mails from summary.
Its not about keeping it permanent in the summary.

>
>> > I definitely won't switch away from maildir as my format of choice
>> > because it integrates nicely with offlineimap.
>>
>> Sure, I think users should have that freedom. Camel's local folder
>> implementation has that built in. This new approach should be the
>> default for new users, and as option for users to migrate to it for
>> existing users. If users willingly stay with maildir or
>> 1mbox-per-folder that should also be there.
>
> In case it wasn't obvious, I don't see the point of diverting resources
> away from an established format in favor of something new. "It's mbox"
> doesn't count, you would have to write the complete directory tree
> handling from scratch.
>
> Of course, it is your time. I'm just expression my concerns as a user of
> the somewhat neglected maildir format.

I appreciate your feedback. Its not a decison. We want to start a
discussion to see how we can improve the existing situation. I really
hate 1mbox per folder design. Maildir isn't the best backend written
in Evo. Given that, I preferred this data cache scheme that other
backends use. Nothing otherwise! We would choose the best that comes
out of this discussion.

-Srini