Re: [Evolution-hackers] Introduction and Questions

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2007-06-07 at 03:05 -0600, Sankar P wrote:
> On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote:

> > 
> > It improves the situation by setting your url-string to have the
> > "basic_headers" option. In the imap code of Camel, it will then ask for
> > less headers (but still way too much).
> 
> May be way too much for a mobile client; but not for a desktop email
> client. Sure you dont want your desktop mail client to have threading or
> show mail-size or have such basic things ?

"When I'm using Evolution on a laptop, I feel very "mobile" too."

btw. This is a quote that I have from Federico, I think (remember) he
said that to me last GUADEC. Although

Very often I'm indeed using my laptop at an airport or something, using
GPRS. Why isn't Evolution suitable for this use-case?

I agree, though, that Tinymail's camel-lite memory improvements are less
of a priority for Evolution. It's bandwidth work, though, is important
in my opinion. Same for the Push E-mail capabilities.

> > A major improvement it certainly isn't.
> 
> Try comparing the performance of fetching all headers and basic_headers
> only. Some crude data which I collected a year back is at
> http://psankar.blogspot.com/2006/05/imap-performance.html

Of course, you can look at the code to see what differs between the
basic_headers mode and the normal one. And that will obviously make a
big difference (the selection of the query is simply a lot smaller).

But if Evolution is causing 900% of its bandwidth to be unnecessary, and
the basic_headers mode saves 400% of that, there is still 500% of it
that is too much. Which is the situation with basic_headers.

The basic_headers option also doesn't implement condstore, which is
quite important to safe bandwidth (if supported by the IMAP server).

> > The best way is to ask for the ENVELOPE and the remaining info using the
> > normal BODY.PEEK method. It should be possible to specify per folder
> > which of the headers are to be fetched, to make it really efficient.
> 
> Do you really think any user on earth will really be interested in
> configuring what headers to fetch on a folder-basis ? 

The application should figure that list out automatically, obviously. 
 
> > ps. In my opinion is also the imap4 project getting the majority of its
> > design wrong. Although it looks better than the "imap" one, it's not the
> > best way to use an IMAP server. If a project is going to write an IMAP
> > client implementation 'today': they better do it right. A lot is
> > changing in IMAP today (Lemonade, MORG, etc). It's important to get it
> > right this time (the vast majority of E-mail clients totally suck at how
> > they use the IMAP server, including Evolution indeed).
> 
> Such a sweeping generalization !?

Maybe, but I've seen quite a lot of their code, and they are indeed very
badly programmed. Most of the custom Camel providers are in a very bad
shape too, by the way.

And ... camel-lite, camel upstream and its standard providers are also
in a bad shape :(

> As you mentioned, IMAP (like any other technology) grows at a very
> high-speed. What you consider as the "right client implementation" today
> may become obsolete tomorrow. When the initial IMAP provider was written
> there may not be a standard spec. for the PUSH/IDLE etc.

This is true. I agree.

> No application can have an intelligent design that will remain forever
> satisfying all new needs/changes. Application designs should just
> evolve, adapting to the new changes.

I also agree with this.

> IIRC, you had a branch on Evolution's Camel to work on whatever changes
> you wanted to make, so that you don't have to wait for the delay due to
> review/maintainer.  Would love to see some of the improvements that you
> have done ported there. So that it becomes easy for the maintainer to
> approve them and bring onto trunk.

I think the best way forward is what Matthew and I share an opinion on:

	To split Camel away from Evolution, and start getting as much of
camel-lite back into that upstream version by making the new function-
ality more and more "pluggable."

It would probably take a few releases to get things in upstream, though.

To do this adventure on my own, I have too much other priorities right
now. If I see somebody being interested, I will definitely help this
person and join his efforts as much as possible.


-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog