Re: [Evolution-hackers] Introduction and Questions

["Sankar P" <psankar novell com>]

On Thu, 2007-06-07 at 12:28 +0300, Philip Van Hoof wrote:
> 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 spend more than 99% of my internet time in a non-GPRS connection. Just
because, I might want to check mail from an airport a few times in a
year, I don't want my mail client to be a minimalistic bare-bones
application all the time. I would rather use a web-based client at these
times. And if I want to use Evolution even in such scenario, then there
is an option to get basic_headers alone as well. (Such option was not
there in last GUADEC though)

> 
> 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 band-width used by Evolution cannot be considered unnecessary, by
comparing with a specific style that is designed for mobiles and
intended to reduce bandwidth. 

It will be good to have CONDSTORE and ENVELOPE (and whatever-new) but it
is not something that makes a user to say, "Damn. I need this and cant
use Evo unless I have it." But there are many other such things that
needs attention and resources.

There are more than 5500 bugs in Evolution and EDS in bgo alone and
among these there is just only one bug that complains about bandwidth.
This bug is filed by you and will eventually benefit the evolution
project once you complete the patch that you are attempting there and
being reviewed by Fejj. 

If Evolution (and hence Gnome as well) has to be successful in an
enterprise level it needs more things like: Better Exchange support,
Nicer and Richer UI, and more importantly Stability. So the Evolution
project's roadmap should be driven based on these, instead of a feature
that is not yet implemented by all the servers.

I am not denying that it is good to have all these bandwidth savings but
Feeping Creaturism(1) should be kept in check.

However, if you feel this is the biggest blocker for a mail-application,
patches are always welcomed :)

> 
> > > 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. 

I still don't understand why you need to get different headers for
different folders.

>  
> > > 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."

You can make all your contributions on the separate branch itself. I
don't understand why you need to split out Camel to contribute to it.

> 
> 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.
> 
> 
-- 
Sankar
(1) - http://en.wikipedia.org/wiki/Creeping_featurism

 Novell, Inc. 
Software for the Open Enterprise™
http://www.novell.com