Re: [Evolution-hackers] Introduction and Questions

2007-06-07 Thread Gilles Dartiguelongue
Le jeudi 07 juin 2007 à 01:53 +0300, Philip Van Hoof a écrit :
 Without immediately writing to disk work, the download by itself will
 consume around 120 MB of RAM, and will most likely fail due to network
 timeouts and other such problems (it'll take a while, since Evolution
 fetches a ridiculous large amount of headers for each message for
 building its summary).
 
isn't the imap-features plugin's goal to reduce/customize the amount of
downloaded headers ? Or is it that it's still not enough ?
-- 
Gilles Dartiguelongue [EMAIL PROTECTED]
EE/CS last year student, ESIEE


signature.asc
Description: Ceci est une partie de message	numériquement signée
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-07 Thread Philip Van Hoof
On Thu, 2007-06-07 at 08:25 +0200, Gilles Dartiguelongue wrote:
 Le jeudi 07 juin 2007 à 01:53 +0300, Philip Van Hoof a écrit :
  Without immediately writing to disk work, the download by itself will
  consume around 120 MB of RAM, and will most likely fail due to network
  timeouts and other such problems (it'll take a while, since Evolution
  fetches a ridiculous large amount of headers for each message for
  building its summary).
  
 isn't the imap-features plugin's goal to reduce/customize the amount of
 downloaded headers ? Or is it that it's still not enough ?

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

A major improvement it certainly isn't.

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.

The imap4 implementation seems to have an ENVELOPE parser, so I guess
either it does it already or it will use ENVELOPE in future.

For a mobile device, that works over GPRS, you for example are usually
not interested (not at all) in the mailinglist specific headers.

It would also be possible to do it in multiple passes. For example get a
modest list of headers, and after that get more and more.

In any case, none of the current Evolution code implements consuming the
CONDSTORE capabilities of some modern IMAP servers (like MBox and
Cyrus).

CONDSTORE is really going to make an enormous difference in bandwidth
consumption with large folders. That's because you only need to fetch
the flags of the changed messages to synchronise flags.

Note that Tinymail's camel-lite implements all the needed solutions to
this bandwidth consumption problem. And that its code is, although a lot
of work because the Evolution maintainers didn't seem interested at the
time it was happening, definitely portable to upstream.

Its implementation include solutions for the headers, it immediately
saves the headers to disk and unlike Evolution's Camel it can resume
partial summary downloads, it wont peek memory allocation during
downloading, it implements Push E-mail using IMAP IDLE and it implements
CONDSTORE.

Although I'm definitely not satisfied with any of either Camel nor
camel-lite's IMAP code. The thing is that I'd much prefer a client-side
implementation that does proper pipelining. For example Infotrope,
Telomer and Polymer does this on an experimental basis (Infotrope is the
library).

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


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




___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-07 Thread Sankar P
On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote:
 On Thu, 2007-06-07 at 08:25 +0200, Gilles Dartiguelongue wrote:
  Le jeudi 07 juin 2007 à 01:53 +0300, Philip Van Hoof a écrit :
   Without immediately writing to disk work, the download by itself will
   consume around 120 MB of RAM, and will most likely fail due to network
   timeouts and other such problems (it'll take a while, since Evolution
   fetches a ridiculous large amount of headers for each message for
   building its summary).
   
  isn't the imap-features plugin's goal to reduce/customize the amount of
  downloaded headers ? Or is it that it's still not enough ?
 
 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 ?

 
 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

 
 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 imap4 implementation seems to have an ENVELOPE parser, so I guess
 either it does it already or it will use ENVELOPE in future.
 
 For a mobile device, that works over GPRS, you for example are usually
 not interested (not at all) in the mailinglist specific headers.

None of the mailing list headers will be fetched if you have chosen the
basic_headers option.

 
 It would also be possible to do it in multiple passes. For example get a
 modest list of headers, and after that get more and more.
 
 In any case, none of the current Evolution code implements consuming the
 CONDSTORE capabilities of some modern IMAP servers (like MBox and
 Cyrus).
 
 CONDSTORE is really going to make an enormous difference in bandwidth
 consumption with large folders. That's because you only need to fetch
 the flags of the changed messages to synchronise flags.
 
 Note that Tinymail's camel-lite implements all the needed solutions to
 this bandwidth consumption problem. And that its code is, although a lot
 of work because the Evolution maintainers didn't seem interested at the
 time it was happening, definitely portable to upstream.
 
 Its implementation include solutions for the headers, it immediately
 saves the headers to disk and unlike Evolution's Camel it can resume
 partial summary downloads, it wont peek memory allocation during
 downloading, it implements Push E-mail using IMAP IDLE and it implements
 CONDSTORE.
 
 Although I'm definitely not satisfied with any of either Camel nor
 camel-lite's IMAP code. The thing is that I'd much prefer a client-side
 implementation that does proper pipelining. For example Infotrope,
 Telomer and Polymer does this on an experimental basis (Infotrope is the
 library).
 
 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 !?

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.

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.


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.

 
 
-- 
Sankar

 Novell, Inc. 
Software for the Open Enterprise*
http://www.novell.com
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-07 Thread Philip Van Hoof
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




___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-06-07 Thread Sankar P
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 

Re: [Evolution-hackers] Introduction and Questions

2007-06-07 Thread Ritesh Khadgaray
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 

Re: [Evolution-hackers] Introduction and Questions

2007-06-07 Thread Jeffrey Stedfast
On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote:
 On Thu, 2007-06-07 at 08:25 +0200, Gilles Dartiguelongue wrote:
  Le jeudi 07 juin 2007 à 01:53 +0300, Philip Van Hoof a écrit :
   Without immediately writing to disk work, the download by itself will
   consume around 120 MB of RAM, and will most likely fail due to network
   timeouts and other such problems (it'll take a while, since Evolution
   fetches a ridiculous large amount of headers for each message for
   building its summary).
   
  isn't the imap-features plugin's goal to reduce/customize the amount of
  downloaded headers ? Or is it that it's still not enough ?
 
 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).

if you set the option to basic headers, it will only fetch the minimal
set of headers required to show the message-list:

DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION
CONTENT-TYPE 

(actually, why is MIME-VERSION in there? it's useless)

 
 A major improvement it certainly isn't.

it's not possible to do better w/o dropping features like message
threading.

In fact, the above minimalizing of header fetching already breaks the
quick context-menu vfolder on mailing-list and filter on
mailing-list features as well as making vfoldering on mailing-list
oodles slower (if it even still works after disabling the headers)

 
 The best way is to ask for the ENVELOPE and the remaining info using the
 normal BODY.PEEK method.

Have you actually ever tested this theory? or did you just pull this out
of your proverbial?

You should note that Thunderbird does not use ENVELOPE, probably because
they found it was LESS efficient to fetch the ENVELOPE +
BODY.PEEK[HEADER.FIELDS (REFERENCES CONTENT-TYPE)] on many existing IMAP
servers in the wild.

Having myself tested this in the past, I don't recall it making much
difference one way or the other.

Sadly using ENVELOPE breaks on at least one proprietary IMAP server
which occasionally likes to send back responses with NIL as each and
every item, at least until a client has issued a BODY.PEEK fetch
request.

  It should be possible to specify per folder
 which of the headers are to be fetched, to make it really efficient.

how do you propose calculating the list of headers each folder should
request? which headers would you eliminate conditionally?

 
 The imap4 implementation seems to have an ENVELOPE parser, so I guess
 either it does it already or it will use ENVELOPE in future.

it fetches:

ENVELOPE BODY.PEEK[HEADER.FIELDS (Content-Type References In-Reply-To)]

and optionally the mailing-list headers

I believe it fetches IN-REPLY-TO (which is included in ENVELOPE)
explicitly because some IMAP servers tried to be smart and parse the
IN-REPLY-TO header for us and didn't handle embedded phrases which
certain broken free-software mailers like to send.

 
 For a mobile device, that works over GPRS, you for example are usually
 not interested (not at all) in the mailinglist specific headers.

this is mobile-device specific tho, when I was implementing imap4 and
people started trying to use it, it was their #1 complaint (which is why
imap4 conditionally requests the mlist headers... tho that flag may be
hard-coded to TRUE now, I'm not sure)

 
 It would also be possible to do it in multiple passes. For example get a
 modest list of headers, and after that get more and more.

but then you introduce a lot more complexity (e.g. scheduling such a
fetch)

slowness for the user (e.g. if he expects to be able to right-click and
select vfolder on mailing-list, he'd have to wait if the info had not
yet been fetched... or even just selecting a mailing-list vfolder)

keep in mind also that this is a one-time fetch, so while opening a
folder for the first time might be slow (if you have 1000's of
messages), future folder selections would take a much more reasonable
amount of time to open (especially with CONDSTORE support which reduces
the FLAGS sync requirements, which is where the real slowness is when
opening a folder for most users)

 
 In any case, none of the current Evolution code implements consuming the
 CONDSTORE capabilities of some modern IMAP servers (like MBox and
 Cyrus).
 
 CONDSTORE is really going to make an enormous difference in bandwidth
 consumption with large folders. That's because you only need to fetch
 the flags of the changed messages to synchronise flags.

yes, this would be nice to have... but as far as I'm aware, it is still
only a draft standard (e.g. it could change).

I would probably not be opposed to a CONDSTORE implementation making it
into upstream camel, tho.

 
 Note that Tinymail's camel-lite implements all the needed solutions to
 this bandwidth consumption problem. And that its code is, although a lot
 of work because the Evolution maintainers didn't seem interested at the
 time it was happening, definitely 

[Evolution-hackers] introduction and an offering

2007-06-07 Thread Roy Pittman
This is my first post to this list.  I have been reading it for a while and 
have a script to offer to all of you but am unsure if this is the right 
place.  Any guidance will be welcome.

The problem:  it is not convenient to move contacts information from MS 
Outlook to Evolution.

My solution: a bash script that will read a dos csv file exported by Outlook 
and re-order that data into a vcard file that Evolution can easily import.

This script works pretty well.  I had fun solving some interesting logic 
problems to make it work.  I want to see it used and to get suggestions for 
improvements.  I have registered my copyright on this script but intend to 
release it under GPL and give it to the community.  I will send this script 
to anyone on this list who is interested.

Thanks,

Roy Pittman


pgp0BaZE3J8QZ.pgp
Description: PGP signature
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers