Re: [Evolution-hackers] The recent camel-lite improvements

[Philip Van Hoof <spam pvanhoof be>]

On Wed, 2007-02-07 at 08:58 -0700, Veerapuram Varadhan wrote:
> On Wed, 2007-02-07 at 11:36 +0100, Philip Van Hoof wrote:
 
> Of all those features/implementations that you have mentioned so far, I
> could list 2 of them fit the interest of evolution - mmap (without
> summary format changes - adding len is okay) and memory-optimization in
> using "tokens" in camel-folder-summary.c. Rest of them are too focused
> and don't provide abstractions to extend for a desktop application.

I agree that most of the changes are indeed focused on mobile uses. I
mentioned the changes in the E-mail because there are some people who
privately and on IRC urge me to synchronize as much as possible of the
work with Evolution's Mailer code.

While I don't disagree with them, I too feel that it's up to the Mailer
maintainers -and people to decide about this. I share your opinion that
most of the changes are not focused on desktop applications.

> Also, I am still on the assumption that you are getting your mmap work
> committed to the mmap-branch, which would be validated and taken during
> the next development cycle and I am yet to see any updates on that.

I wrote this down, and will take a look at what I can extract from the
current camel-lite version into the current Camel version of Evolution.

If somebody wants to speed this up, assistance is welcomed :)

Note though that I'm planning to implement a very different idea on the
summary work. Something with mmap()ed segments (multiple summary files
per folder, on the disk) of 1,000 summary items per segment and putting
the flags in a separate file.

Might sound a little bit overkill too. So I might withdraw from the idea
too. It's just that I have certain performance issues when locally
searching, that could more easily be solved this way.

> > Although I *AM* actively going to help the person who will port this
> > stuff to Evolution's Camel. By that I mean that I *will* make time for
> > this person. A lot if necessary. Entire evenings of free time if I have
> > to.
> > 
> > It's not so much about *time* itself, it's 100% about loosing it on
> > something that wont be acted upon anyway. Nobody enjoys that, I
> > certainly don't.
> > 
> We appreciate that and looking forward to get the good work merged soon.

Thanks.