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. _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
