Re: [Evolution-hackers] Introduction and Questions

[Ritesh Khadgaray <khadgaray gmail com>]

On Thu, 2007-06-07 at 04:56 -0600, Sankar P wrote:
> 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)

On Evoluion 2.10, i see a option for basic headers . 

Edit -> preferences -> mail account -> 
select your imap account -> edit -> IMAP headers -> Basic headers


> 
> > 
> > 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.
> > 
> > 
-- 
Ritesh Khadgaray
ॐ मणि पद्मे हूँ
LinuX N Stuff
Ph: +919970164885
Eat Right, Exercise, Die Anyway.