Re: [Evolution-hackers] Introduction and Questions
- From: Philip Van Hoof <spam pvanhoof be>
- To: Jeffrey Stedfast <fejj novell com>
- Cc: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] Introduction and Questions
- Date: Fri, 08 Jun 2007 18:34:36 +0300
On Fri, 2007-06-08 at 09:48 -0400, Jeffrey Stedfast wrote:
> I think the laptop problem is solved with the "basic headers" feature,
> at least as far as collecting new summary info is concerned.
>
> Syncing flags is another story, and where the real
> slowness/user-frustration lies.
>
> I'm sure David Woodhouse would agree here.
ps. The condstore work in camel-lite is the most easy part to migrate.
> > Right now any change that isn't absolutely 100% super pro and for
> > Evolution and Evolution only, gets ignored by you guys at Novell.
>
> I would argue that not to be the case. I would instead argue that the
> reason many of your patches haven't been incorporated into Camel is
> that they are hackish and/or tailored explicitly for /your/ needs, and
> not for the good of the many.
I agree that a lot of the things are hackish, some of the changes are
this way because there are some design problems in Camel that make
certain things not possible without such hacks.
For example the fact that non-blocking read()s are not possible by the
default CamelStream things, and that none of the existing code really
copes very well with non-blocking reads.
The imap4 project is making things look better, though all in all it's
still much of the same (blocking and waiting for results, in stead of
letting the server do most the work and do pipelining).
> That's not the one I was thinking of, actually... I was more thinking
> of the BODY(STRUCTURE) stuff.
Camel-lite doesn't use BODYSTRUCTURE, it only uses body.peek[0] for
doing a partial retrieval. I'm, however, planning to let the
CamelMimePart late fetch not-yet retrieved parts when needed (in stead
of always downloading the full, or only the body part of the message).
That would conflict with IMAP servers that don't do mime parsing right.
> Then don't be so negative. I'd hardly say that imap4 has a majority of
> its design wrong.
> Try some constructive criticism for a change...
You are right, let's try to criticise constructive. My apologises for
the negative way of putting that I don't like how imap4 is designed.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]