On Wed, 2009-12-16 at 16:54 +0530, Srinivasa Ragavan wrote:
> On Wed, Dec 16, 2009 at 4:46 PM, Patrick Ohly <patrick.o...@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

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"

> 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.

> > 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.

Bye, Patrick Ohly

Evolution-hackers mailing list

Reply via email to