On Thu, 2007-05-31 at 14:10 -0400, Jeffrey Stedfast wrote:
> 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 :(
Maybe it's time to plan this on the wiki ?
>
> >
> > 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
This is one of the reasons we independent instances across mail,
calendar, contacts, etc would be good. Easier debugging, isolation of
problems, performance tune up, all by component in a far easier way,
IMHO.
>
> (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
>
