Re: [Evolution-hackers] Introduction and Questions

[Jeffrey Stedfast <fejj novell com>]

On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote:
> Hi.  I've been getting into the code of evolution recently, and am thinking of 
> doing a bit more to see if I can get it working OK for my situation.  I have 
> an IMAP mailbox which is very large, both in terms of folders (over 100) and 
> messages (the largest folder has >300,000 messages; my INBOX has about 
> 22,000).

the largest INBOX I've ever used was about ~100,000 messages, so you may
get to have some fun :)

> 
> None of the email clients I've tried cope with this very well.  Since I've 
> been using evo at work in a similar setup (cyrus server, though not quite as 
> big), I thought it might be the best to try to tweak.  The problems I've had 
> so far involve setup activities rather than core functionaility.  First, 
> evolution couldn't create the account (solved); second I've had problems 
> getting it to show all of my subfolders.

are they in different namespaces? Current evo IMAP provider doesn't
handle multiple namespaces :(

> 
> My narrow question is how to debug evolution.  When I launched evolution in 
> gdb evolution (the GUI) came up, and then the debugger told me the process 
> had exited (though the GUI was up and running).  I believe the initial 
> process does some kind of activation of the "real" process and then exits.

sounds like you already had an instance of Evolution running (on another
virtual desktop perhaps?)

Evolution only allows one instance of itself to be running for the same
user account... if you try to start a second instance, it signals the
original instance to open a new window and then exits.

> 
> I know I can attach to the second process, but I think the stuff I need to see 
> happens at startup.  So how can I get a debugger on the startup process of 
> the "real" evolution?

should just be able to do gdb evolution

(Note: I haven't debugged evolution in over a year since I've moved onto
other projects, but that's how I always debugged it)

> 
> I tried to search the archive, but the search function seems broken: it 
> searches everything, even though it says "search this list only."
> 
> Also, evolution seems to have two presences on the web: a web site and a wiki.  
> The developer stuff on the web site is old, and has no pointers to the newer 
> stuff that I could find.  It would be good if it did.
> 
> I have some broader questions too, if anyone has any comments on them.
> 
> What version to start with?  I'm on Debian GNU/Linux, which currently has evo 
> 2.6.  I notice that's a bit dated (although I did see that a few months ago 
> some of the Debian packagers were interested in making a more recent 
> version).  I've been working from the Debian version.  Does that version, the 
> last stable release (from evo, not Debian), or svn head make the most sense 
> to work from?  (BTW, the one bug I fixed was one that was already fixed 
> post-2.6).

probably best to start with 2.10(.2) (or svn if you are brave) so as to
avoid spending time fixing things that have already been fixed.

> 
> Mission Impossible?  Am I likely to get anywhere without spending lots of 
> time?

I guess the answer to this is all relative... :)

>   I'm a professional software developer, but I'm not familiar with 
> GNOME, and this is clearly a complex application.
> 
> Mission Advisable?  If I get past the setup hurdles, is evolution likely to be 
> able to handle the mail store I described?

I think it'll be possible, there's lots of improvement that can be made
to the current imap code :)

> 
> How do I find out which of the imap store's code I'm actually using?

you are probably using the provider in
evolution-data-server/camel/providers/imap

- imap4 is a project I started to replace the current imap provider and
works fairly ok, but isn't quite complete (I forget all what it is
missing since it's been a few years since I actively hacked on it - I
think the main thing is cached search results?). This provider, like the
current imap backend, suffers from being synchronous, but it is far
better designed and much cleaner code to read. This backend also
supports multiplenamespaces (tho it'd be better if the Camel API
included multiple-namespace support, the way it works in imap4 is
because all folders are listed from a toplevel namespace rather than
from individual namespaces like it should).

- imapp is an old attempt at making a pipelined imap provider, tho it is
basically a dead-end at this point.

- imapx is yet another attempt at replacing the current imap backend but
depends on a lot of unfinished stuff in a development branch that has
been abandoned for about 2 years now I think (the guy that had been
working on that quit)


Jeff