tag:old.nabble.com,2006:forum-1297Nabble - Gnome - Evolution2009-11-23T14:38:46ZEvolution provides integrated mail, addressbook and calendaring functionality to users of the GNOME desktop. Gnome - Evolution home is <a href="http://www.gnome.org/projects/evolution/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26487406Re: connect Evolution 2.28 to MS exchange 2007 on Fedora 122009-11-23T14:38:46Z2009-11-23T14:38:46ZNg Oon-EeOn Mon, 2009-11-23 at 15:14 -0500, Art Alexion wrote:
<div class='shrinkable-quote'><br>> Ng Oon-Ee wrote:
<br>> >
<br>> > On Sat, 2009-11-21 at 08:35 +0100, Jean-Claude Tergal wrote:
<br>> > > 2009/11/19 L <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26487406&i=0" target="_top" rel="nofollow">yuanlux@...</a>>:
<br>> > > >>> One of main reasons for upgrade F11 to F12 was to hope to connect
<br>> > > >>> evolution 2.28 to Exchange 2007. After a smooth upgrade to F12. I
<br>> > > >>> tried to connect evolution 2.28 with evo-mapi to M$ exchange server.
<br>> > > >>> no luck at all, it crashed every time. The insttiute's exchange
<br>> > server
<br>> > > >>> does not open imap port. i you have sucessful connection, please
<br>> > > >>> share with me
<br>> > >
<br>> > > I have a successful connection, but my compagny is using Exchange 2003
<br>> > > ; and the evolution-exchange RPM of Mandriva 2010 says "Currently,
<br>> > > only Exchange 2000 and 2003 are supported". So, it seems that Exchange
<br>> > > 2007 is not supported at all ; I think you have to stay with
<br>> > > VirtualBox, or use the bloody Outlook Web Access in Firefox.
<br>> > >
<br>> > > Nicolas
<br>> > > Strasbourg (France)
<br>> >
<br>> > I have a successful connection with Exchange 2007. Evo-mapi crashes
<br>> > immediately in release 2.28.0, you need 2.28.1 where the fixes are. I'm
<br>> > not familiar with F12 or indeed anything about Fedora, but you may need
<br>> > to talk to the maintainer of gnome/evolution/evo-mapi for your distro.
<br>> >
<br>> You are lucky. I have 2.28.1, but evolution crashes as soon as I try to
<br>> authenticate. Thunderbird works fine with DAVMail, but Lightning as the
<br>> calendar provider is quite flaky. Evolution's caldav won't connect to
<br>> davmail at all. Nothing seems to connect to the GAL.
<br>>
<br>> So, I run Tbird/DavMail for mail and installed a stripped down version
<br>> of XP in virtual box, stripped it down some more, installed Outlook, set
<br>> the registry so that shell=outlook.exe, and am using it as a
<br>> calendar/addressbook appliance. I am patiently hoping that
<br>> evolution-mapi will work as well as evolution-exchange some day and I
<br>> can go back to using a native Linux solution.
<br>>
<br>> Evolution was the reason I ran gnome on my work machine.
<br>>
<br>> <sigh>
<br>>
</div>I don't think it has anything to do with luck, I simply looked for a
<br>version that works and compiled it. Various distros patch things up
<br>according to my needs, mine doesn't so less possibility of introduced
<br>bugs.
<br><br>If you're okay with compiling from source, get the git of evo-mapi from
<br>the 2.28.0 label and apply the next 4 patches in git, that's the ones
<br>that fix crashing for me.
<br><br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26487406&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26485074Re: connect Evolution 2.28 to MS exchange 2007 on Fedora 122009-11-23T12:14:51Z2009-11-23T12:14:51ZArt Alexion-4Ng Oon-Ee wrote:
<div class='shrinkable-quote'><br>>
<br>> On Sat, 2009-11-21 at 08:35 +0100, Jean-Claude Tergal wrote:
<br>> > 2009/11/19 L <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26485074&i=0" target="_top" rel="nofollow">yuanlux@...</a>>:
<br>> > >>> One of main reasons for upgrade F11 to F12 was to hope to connect
<br>> > >>> evolution 2.28 to Exchange 2007. After a smooth upgrade to F12. I
<br>> > >>> tried to connect evolution 2.28 with evo-mapi to M$ exchange server.
<br>> > >>> no luck at all, it crashed every time. The insttiute's exchange
<br>> server
<br>> > >>> does not open imap port. i you have sucessful connection, please
<br>> > >>> share with me
<br>> >
<br>> > I have a successful connection, but my compagny is using Exchange 2003
<br>> > ; and the evolution-exchange RPM of Mandriva 2010 says "Currently,
<br>> > only Exchange 2000 and 2003 are supported". So, it seems that Exchange
<br>> > 2007 is not supported at all ; I think you have to stay with
<br>> > VirtualBox, or use the bloody Outlook Web Access in Firefox.
<br>> >
<br>> > Nicolas
<br>> > Strasbourg (France)
<br>>
<br>> I have a successful connection with Exchange 2007. Evo-mapi crashes
<br>> immediately in release 2.28.0, you need 2.28.1 where the fixes are. I'm
<br>> not familiar with F12 or indeed anything about Fedora, but you may need
<br>> to talk to the maintainer of gnome/evolution/evo-mapi for your distro.
<br>>
</div>You are lucky. I have 2.28.1, but evolution crashes as soon as I try to
<br>authenticate. Thunderbird works fine with DAVMail, but Lightning as the
<br>calendar provider is quite flaky. Evolution's caldav won't connect to
<br>davmail at all. Nothing seems to connect to the GAL.
<br><br>So, I run Tbird/DavMail for mail and installed a stripped down version
<br>of XP in virtual box, stripped it down some more, installed Outlook, set
<br>the registry so that shell=outlook.exe, and am using it as a
<br>calendar/addressbook appliance. I am patiently hoping that
<br>evolution-mapi will work as well as evolution-exchange some day and I
<br>can go back to using a native Linux solution.
<br><br>Evolution was the reason I ran gnome on my work machine.
<br><br><sigh>
<br><br>--
<br>Art Alexion
<br>MIS/Central Office Support
<br>Resources for Human Development
<br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26485074&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26484810Re: Suggestions that would make it possible for me to fully migrate to Linux via Evolution2009-11-23T11:58:20Z2009-11-23T11:58:20ZArt Alexion-4On 11/20/2009 Bryan Karlan wrote:
<br>> I am a power-user of Outlook and am interested in fully migrating
<br>> to Ubuntu and Evolution. I have tried Outlook with Wine, but that
<br>> was a waste of time. I push Outlook to the limits and am hesistant
<br>> to purchase a $300 copy of a full install of Windows7 Ultimate and a
<br>> $500 copy of Office 2010 in 6 months. I believe that Linux has
<br>> become a real alternative for a business user and because of this I
<br>> have joined your site to offer some advice that would improve the
<br>> usability of Evolution.
<br><br>Brian,
<br><br>Just because you can push Outlook to technical limits doesn't mean it is
<br>is good idea to do so. Please avoid HTML and unnecessary graphics in
<br>technical lists.
<br><br>Now, tell us some things about your set up. What will you be using as a
<br>backend? IMAP? POP? Exchange? If Exchange, what version? Will you be
<br>connecting to the mail server over the LAN or WAN?
<br><br>--
<br>Art Alexion
<br>MIS/Central Office Support
<br>Resources for Human Development
<br><br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26484810&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26478699Re: resproduceable crash of Evo 2.24.52009-11-23T06:07:59Z2009-11-23T06:07:59ZPete Biggs<br>>
<br>> Could someone with 2.26 check if the bug is still there; it is only a
<br>> few mouse clicks away :-)
<br>>
<br><br>The file selection dialogue is different. There's no place to type
<br>anything in, it's all done through mouse clicks. It may be that it is
<br>different because the file selection boxes are different between Gnome
<br>and FreeBSD, or because it has changed going from 2.24->2.26.
<br><br>P.
<br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26478699&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26478473Re: resproduceable crash of Evo 2.24.52009-11-23T05:55:59Z2009-11-23T05:55:59ZMatthias Apitz-4El día Monday, November 23, 2009 a las 01:44:26PM +0000, Constantin Or??san escribió:
<br><br>> I don't know what distribution you use, but the most likely answer is
<br>> to upgrade your evolution (which in many cases means upgrading your
<br>> distributions). The current version is 2.28.x
<br><br>I'm running a FreeBSD 8-CURRENT from SVN as of May this year and this has the
<br>2.24,5 in its ports collection; in december I will update to 9-CURRENT
<br>which brings 2.26.3; as far as I know a binary 2.28 is not available and
<br>it would be a pain to compile it by my own I think;
<br><br>> If I remember correctly 2.24 -> 2.26 required major changes, so it is
<br>> very likely that the bug disappeared (and others got introduced :)
<br><br>Could someone with 2.26 check if the bug is still there; it is only a
<br>few mouse clicks away :-)
<br><br>Thx
<br><br> matthias
<br><br>--
<br>Matthias Apitz
<br>t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
<br>e <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26478473&i=0" target="_top" rel="nofollow">guru@...</a>> - w <a href="http://www.unixarea.de/" target="_top" rel="nofollow">http://www.unixarea.de/</a><br>Vote NO to EU The Lisbon Treaty: <a href="http://www.no-means-no.eu" target="_top" rel="nofollow">http://www.no-means-no.eu</a><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26478473&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26478276Re: resproduceable crash of Evo 2.24.52009-11-23T05:44:26Z2009-11-23T05:44:26ZConstantin OrăsanHi,
<br><br>> I can reproduce a crash of Evo by just kicking:
<br>>
<br>[...]
<br>>
<br>> ---> crash
<br>>
<br>> Is it worth to file a bug report somewhere, where?
<br>>
<br><br>I don't know what distribution you use, but the most likely answer is
<br>to upgrade your evolution (which in many cases means upgrading your
<br>distributions). The current version is 2.28.x
<br><br>If I remember correctly 2.24 -> 2.26 required major changes, so it is
<br>very likely that the bug disappeared (and others got introduced :)
<br><br>Regards
<br><br>Constantin
<br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26478276&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26477855resproduceable crash of Evo 2.24.52009-11-23T05:16:13Z2009-11-23T05:16:13ZMatthias Apitz-4<br>Hello,
<br><br>I can reproduce a crash of Evo by just kicking:
<br><br>- click button New message
<br>- click Attachment button
<br>- type in the Location field: the chars /tmp/repli (because I know that
<br> the files with this name are there);
<br> which gives me 3-4 files starting with "/tmp/repli"
<br>- select the last one with the mouse
<br><br>---> crash
<br><br>Is it worth to file a bug report somewhere, where?
<br>Thx
<br><br> matthias
<br>--
<br>Matthias Apitz
<br>t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
<br>e <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26477855&i=0" target="_top" rel="nofollow">guru@...</a>> - w <a href="http://www.unixarea.de/" target="_top" rel="nofollow">http://www.unixarea.de/</a><br>Vote NO to EU The Lisbon Treaty: <a href="http://www.no-means-no.eu" target="_top" rel="nofollow">http://www.no-means-no.eu</a><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26477855&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26477483Re: Retrieve signal of 'Junk' / 'Not Junk' button in Evolution mail2009-11-23T04:48:59Z2009-11-23T04:48:59ZMilan CrhaOn Mon, 2009-11-23 at 18:00 +0800, Arumugam Vkk wrote:
<br>> My team created a spam filter that is being integrated into Evolution
<br>> mail for our final year project. We have no problem reading the mails
<br>> and everything is almost complete. Currently working on the retraining
<br>> of Bayesian and we need to know how do we retrieve the signal when we
<br>> click the 'junk' / 'not junk' button.
<br><br> Hi,
<br>have a look how's done the bogofilter junk plugin
<br><a href="http://git.gnome.org/cgit/evolution/tree/plugins/bogo-junk-plugin" target="_top" rel="nofollow">http://git.gnome.org/cgit/evolution/tree/plugins/bogo-junk-plugin</a><br>or the SpamAssassin plugin
<br><a href="http://git.gnome.org/cgit/evolution/tree/plugins/sa-junk-plugin" target="_top" rel="nofollow">http://git.gnome.org/cgit/evolution/tree/plugins/sa-junk-plugin</a><br>in evolution. Doing your spam plugin the similar way you'll be able to
<br>choose it in Edit->Preferences->Mail Preferences, tab Junk. (Maybe you
<br>have it that way already, I do not know.)
<br> Hope that helps,
<br> Milan
<br><br>_______________________________________________
<br>Evolution-hackers mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26477483&i=0" target="_top" rel="nofollow">Evolution-hackers@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-hackers" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-hackers</a><br><p>From forum: <a href="http://old.nabble.com/Gnome---Evolution---Dev-f1298.html" embed="fixTarget[1298]" target="_top" >Gnome - Evolution - Dev</a></p>tag:old.nabble.com,2006:post-26476436(no subject)2009-11-23T03:38:36Z2009-11-23T03:38:36ZAndrea Cusano<html><head></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26476436&i=0" target="_top" rel="nofollow">andrea_maradona_cinese@...</a><br></div>
<!-- cg13.c41.mail.ird.yahoo.com compressed/chunked Mon Nov 23 03:35:37 PST 2009 -->
</div><br>
</body></html><br />_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26476436&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26475853Problems with Fedora 12 & Evolution2009-11-23T02:48:08Z2009-11-23T02:48:08ZAllen Meyers-2I am not overly fond of gmail, I use it to fetch my mail from yahoo,
<br>but I do like and am very fond of gnome and evolution mail.
<br>As I explore various Linux OS I simply restore my previous setting and
<br>I was always good to go with 8 different OS until now.
<br>Evolution in Fedora 12 first seemingly went through the process
<br>initially of accepting the restoration, but in fact when I attempted
<br>to send I realizes there was no contacts.
<br>(have huge contact list) So I thought well if I have to I will start
<br>over with a smaller list in my new evolution. Not taking into account
<br>my pop 3 information would not be there as well so cannot send or
<br>receive.
<br>What is the best method at this point to get back to a working
<br>evolution mail.
<br><br>Thanks so much
<br>Allen Meyers
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26475853&i=0" target="_top" rel="nofollow">texas.chef94@...</a>
<br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26475853&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26475248Retrieve signal of 'Junk' / 'Not Junk' button in Evolution mail2009-11-23T02:00:19Z2009-11-23T02:00:19ZArumugam Vkk<html><head></head><body><div style="font-family:tahoma,new york,times,serif;font-size:10pt;color:#000000;"><div>Hey everyone,<br><br>My team created a spam filter that is being integrated into Evolution mail for our final year project. We have no problem reading the mails and everything is almost complete. Currently working on the retraining of Bayesian and we need to know how do we retrieve the signal when we click the 'junk' / 'not junk' button.<br><br>Please help. Thank you.<br><br>Regards,<br>Aru<br></div>
<!-- cg12.c60.mail.sg1.yahoo.com compressed/chunked Mon Nov 23 01:26:52 PST 2009 -->
</div><br>
<hr size=1> <a href="http://sg.rd.yahoo.com/sg/mail/domainchoice/mail/signature/*http://mail.promotions.yahoo.com/newdomains/sg/" target="_top" rel="nofollow"> New Email addresses available on Yahoo! </a> <br> Get the Email name you've always wanted on the new @ymail and @rocketmail.<br>
Hurry before someone else does!</body></html><br />_______________________________________________
<br>Evolution-hackers mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26475248&i=0" target="_top" rel="nofollow">Evolution-hackers@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-hackers" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-hackers</a><br><p>From forum: <a href="http://old.nabble.com/Gnome---Evolution---Dev-f1298.html" embed="fixTarget[1298]" target="_top" >Gnome - Evolution - Dev</a></p>tag:old.nabble.com,2006:post-26463797Re: Camel Manifesto2009-11-22T01:34:27Z2009-11-22T01:34:27ZChenthill-2On Sat, 2009-11-21 at 14:57 +0530, Sankar P wrote:
<div class='shrinkable-quote'><br>> On Sat, Nov 21, 2009 at 12:51 AM, Jeffrey Stedfast <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26463797&i=0" target="_top" rel="nofollow">fejj@...</a>>
<br>> wrote:
<br>> > Matthew Barnes wrote:
<br>> >> With work on Bonobo removal wrapping up, I've finally started
<br>> taking a
<br>> >> closer look at Camel (Evolution's mail storage and networking
<br>> library)
<br>> >> and laying out plans for where I'd like it to go over the short and
<br>> long
<br>> >> term, with the ultimate goal of splitting it off as a useful
<br>> standalone
<br>> >> GNOME library (but we're a long way from that).
<br>> >>
<br>> >> As usual I'm taking a bottom-up approach, starting with basic
<br>> cleanup
<br>> >> chores (both code and development policies) and building up from
<br>> there.
<br>> >> Here's some of my thoughts:
<br>> >>
<br>> >>
<br>> >> Backward Compatibility Policy
<br>> >> -----------------------------
<br>> >>
<br>> >> A reverse dependency search in Debian and Fedora reveals the only
<br>> >> external projects currently linking to Camel are mail-notification,
<br>> >> evolution-jescs and Anjal (please correct me if I've missed any).
<br>> >>
<br>> >> That tells me that until Camel moves out of its parents' basement
<br>> and
<br>> >> matures into an real, honest-to-goodness library, fixing its
<br>> interface
<br>> >> is more important than maintaining backward compatibility.
<br>> Deprecation
<br>> >> periods for obsolete API are not necessary, in my opinion. The
<br>> few
<br>> >> external projects linking to Camel will just have to keep up with
<br>> the
<br>> >> changes every six months.
<br>> >>
<br>> >
<br>> > I think it's a worthy goal to separate Camel out of Evolution.
<br>> >
<br>> >> That's not a license to go hog wild though. Some caveats:
<br>> >>
<br>> >> 1) The soname -must- be kept accurate. If you break the API or
<br>> ABI,
<br>> >> increment the soname when you commit the break. It doesn't
<br>> matter if
<br>> >> the break doesn't affect external projects, nor even if it's
<br>> already
<br>> >> been incremented since the last point release. Bump it
<br>> anyway.
<br>> >> "Always bump" is an easy policy to remember. It makes our
<br>> own daily
<br>> >> development run smoother, and helps ensure a release doesn't
<br>> slip out
<br>> >> with an inaccurate soname.
<br>> >>
<br>> >> If you're not sure if your patch requires a soname increment,
<br>> please
<br>> >> ask in IRC or Bugzilla. Patch reviewers should try to
<br>> remember too.
<br>> >>
<br>> >> 2) If you must break the API, try to do so in a way that things
<br>> will
<br>> >> fail noisily at build time rather than mysteriously at run
<br>> time. For
<br>> >> example, if you want to change the behavior of an existing
<br>> function,
<br>> >> it's better to rename the function or change its parameter
<br>> list so
<br>> >> that stale Evolution code will fail to build.
<br>> >>
<br>> >> 3) Camel started life as a general purpose mail library and I'd
<br>> like to
<br>> >> try to get back to that. Camel has become too
<br>> Evolution-centric in
<br>> >> my view, with too many quick-fix hacks for Evolution bugs that
<br>> would
<br>> >> not be appropriate for a general purpose mail library. I
<br>> will clean
<br>> >> these up as I find them, but try to keep that in mind when
<br>> altering
<br>> >> the API yourself.
<br>> >>
<br>> >
<br>> > I'm not sure what Evolution-specific quick-fix hacks you mean?
<br>> >
<br>> >>
<br>> >> Migrate to GObject
<br>> >> ------------------
<br>> >>
<br>> >> Camel's homegrown type system will be replaced with GObject so that
<br>> >> introspection and D-Bus + language bindings are possible.
<br>> CamelObject
<br>> >> will remain (for now), but as a subclass of GObject. The
<br>> redundant
<br>> >> parts of CamelObject will be removed.
<br>> >>
<br>> >
<br>> > Worthy goals... there are some things like CamelObjectBag and such
<br>> that
<br>> > don't have an equivalent in GObject.
<br>> >
<br>> >> I'm also following GLib and GTK+'s example of sealing up public
<br>> instance
<br>> >> data in private sections and enforcing that only its top-level
<br>> header
<br>> >> file be included outside of Camel (including the providers).
<br>> Unlike
<br>> >> GLib and GTK+, there will be no transition period.
<br>> >>
<br>> > Okay.
<br>> >
<br>> >> This will give us a lot more freedom to reorganize the library and
<br>> >> refactor code without disturbing the ABI. Debugging is also
<br>> easier when
<br>> >> you can trap data accesses through "get" and "set" functions.
<br>> >>
<br>> >
<br>> > Sure, but I don't think any code actually goes behind any get/set
<br>> > method's back at the moment (or at least didn't back when I worked
<br>> on
<br>> > Camel). Regardless, I'm cool with the proposed changes...
<br>> >
<br>> >> I've been chipping away at this as a side project for the past year
<br>> (it
<br>> >> was a good mindless activity when I got burned out on Bonobo
<br>> removal),
<br>> >> and I recently published my results to git.gnome.org as a branch
<br>> named
<br>> >> "camel-gobject". The CamelObject conversion is finished --
<br>> including
<br>> >> all the boilerplate changes in the subclasses -- but I haven't
<br>> finished
<br>> >> sealing up the API.
<br>> >>
<br>> >> The branch probably won't land until 2.31 at the earliest. The
<br>> backward
<br>> >> compatibility policies I described above would be in effect
<br>> thereafter.
<br>> >>
<br>> >>
<br>> >> Kill CamelStream
<br>> >> ----------------
<br>> >>
<br>> >> This is a distant future goal and will have to happen gradually,
<br>> but I
<br>> >> would like Camel to shift to a single-threaded design where all
<br>> file and
<br>> >> network operations directly use or are derived from GIO's
<br>> asynchronous
<br>> >> file and stream APIs. SSL support is currently under development
<br>> for
<br>> >> GIO, and that's the only missing piece I see at the platform layer.
<br>> >>
<br>> >> I realize this is a drastic course correction and will require
<br>> rewriting
<br>> >> all the providers and much of the mailer code in Evolution, but I
<br>> firmly
<br>> >> believe that the overuse of threads carries much of the blame for
<br>> >> Evolution's chronic instability over the years and that reversing
<br>> that
<br>> >> trend first and foremost requires minimizing our use of threads for
<br>> I/O
<br>> >> and relying more heavily on GLib's main loop.
<br>> >>
<br>> >>
<br>> >> Comments and constructive criticism encouraged.
<br>> >>
<br>> >
<br>> > I agree with Michael Meeks' concerns here. I also think there are
<br>> much
<br>> > more important fish to fry which are also far easier to tackle.
<br>> >
<br>> > An IMAP rewrite (which supports IDLE) seems to be something a lot of
<br>> > users would be very thankful for, for example. The ancient IMAP code
<br>> > that is still being used by default (afaik) is probably one of the
<br>> > biggest sources of frustration for both users and maintainers (it
<br>> also
<br>> > has a reputation for being the biggest source of race
<br>> > conditions/deadlocks in all of Evolution - which seems to be your
<br>> > primary reason for making Camel async ;-)
<br>> >
<br>>
</div>I have taken the imapx implementation by Notzed and currently porting to
<br>the db summary. With this support like IDLE should be pretty simple.
<br>Once the features are in parity with the default imap, we would make
<br>imapx as the default. Am working on this for evolution 2.30.
<br><br><div class='shrinkable-quote'><br>> I absolutely agree. I am reminded of some of the code comments that
<br>> used to exist like: "There are so many broken IMAP servers out there",
<br>> "Hack to handle the broken Exchange 2005 IMAP access" etc. Evolution
<br>> now has far more providers to support and far less people to work on,
<br>> than say two years ago. So, I might actually suggest that we rely on
<br>> something like "offlineimap" to do the networking part. Evolution can
<br>> then just work on the maildir provided by the mail fetching daemon.
<br>> since offlineimap supports signals, you can map "get-mail" events
<br>> also. the only problem is that the service will be disconnected and
<br>> all mails will be fetched.
<br>>
</div><br>It is clear that we have less active developers at the moment than
<br>before and the efforts have been carefully planned in selected areas.
<br>offlineimap may not be a solution for users who do not want to
<br>cache the mails. A typical use case for mobile based apps. So our target
<br>is both desktop and mobile based apps.
<br><br>Perhaps I had thought about in-corporating the gnio changes and making
<br>the imap implementation alone a bit outside of camel of other apps also
<br>to make use. But ssl support in gnio made me drop that plan. I am
<br>strongly in favor of migrating from evolution specific libraries to glib
<br>based ones.
<br><br>OTOH I am impressed with the amount of choices which linux provides,
<br>with so many email clients who keeps competing and improving.
<br><br>> Though everyone likes to write new code, I am sure it will cause a lot
<br>> of maintenance problems with so many providers to support. Camel can
<br>> just be mail library that runs as a service and provides a single
<br>> point of api for other tools (Tracker/Beagle, OpenOffice, whatever).
<br>> Internally it makes use of offlineimap, smtp, GW-MUA for whatever mail
<br>> transport.
<br>So a good news, Travis Reitter (treitter), Jonathon Jongsma (jonner)
<br>have started the work on mailer-to-eds :-)
<br><div class='shrinkable-quote'><br>>
<br>> > The sqlite backend stuff could also use some work. As far as I'm
<br>> aware,
<br>> > the tables are non-optimal. At one point I noticed that UIDs (the
<br>> > primary key in the table) were stored as strings - it would be
<br>> better to
<br>> > store them as uint32s (yes, I know the gw and exchange backends do
<br>> not
<br>> > use uint32s for UIDs) for performance reasons. It should be possible
<br>> for
<br>> > these backends to have a second table which mapped the canonical
<br>> uint32
<br>> > UID key to the key used by the servers.
<br>> >
<br>>
<br>> Yes. when Srini and I started with the sqlite summary work, we planned
<br>> to implement the basic workflow first and then to improve the database
<br>> in more effective ways. But sadly none of us work anymore on
<br>> Evolution directly and we weren't aware of these surprises when we
<br>> implemented the initial version of sqlite summary.
<br>>
<br>> One important area that could improve immensely is Search. We now do a
<br>> "Like '<string>'" query on database often leading to slowed search
<br>> results. We can create more indices and once the user starts typing in
<br>> the text box, we can autocomplete adn do a EXACT Search in teh
<br>> database often leading to faster results. For instance, if I search
<br>> for Fejj now the query that goes to db is LIKE FEJJ. Whereas, if we
<br>> can autocomplete during the search and show <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26463797&i=1" target="_top" rel="nofollow">fejj@...</a>, then in
<br>> the database it is faster to search with a EXACT match. this may not
<br>> look like a big improvement in theory but I believe it will be a big
<br>> usability improvement and can also of be use for other applications
<br>> that will rely on us, when camel becomes a service etc. Sadly, I was
<br>> never able to make the management understand the need for this when I
<br>> was in the team and also we never had the time to complete the
<br>> disk-summary migration and other related tasks etc.
<br>>
<br>> > Additionally, the way Camel current works (even now, with the sqlite
<br>> > backend), when a folder is opened, the entire summary for the folder
<br>> is
<br>> > loaded the same as it used to be before the sqlite changes. This
<br>> seems
<br>> > rather... wasteful? Kinda defeats the purpose of using sqlite (or
<br>> any
<br>> > other database backend). The main problem with the older format is
<br>> that
<br>> > it did not allow random-access, which means we really needed to load
<br>> the
<br>> > whole thing into memory for a number of reasons:
<br>> >
<br>> > 1. each record being a different size requires sequential
<br>> access
<br>> > from disk
<br>> > 2. can't sort by sender, subject, date (or whatever) until you
<br>> have
<br>> > the entire summary in memory
<br>> > 3. doing lookups on message UIDs would be prohibitively slow
<br>> from disk
<br>> >
<br>> > With a db backend, none of these problems exist any longer. Some
<br>> Camel
<br>> > APIs would likely need to change in order to support taking
<br>> advantage of
<br>> > this new feature, but it's something that needs to be done.
<br>> >
<br>>
<br>> IIRC, For showing in message list, we already fetch only whatever
<br>> records are needed and do not load the full summary onto the memory.
<br>> For instance, if you have selected "Unread mail" in the QuickShow
<br>> combo box, only unread mails' summary items are loaded.
<br>>
<br>> >
<br>> > These things seem like much bigger wins for Camel's (and, by
<br>> extension,
<br>> > Evolution's) usability/maintainability than making Camel async and
<br>> are
<br>> > also far more trivial to implement.
<br>> >
<br>> > Just some things to think about...
<br>> >
<br>>
<br>> I tend to agree with Fejj on this and I am big fan of threads. But I
<br>> no longer work on evo and knowing Matthew I believe he knows what is
<br>> the best. All the best :-)
</div>We are all part of evolution community :) So would be good not to say,
<br>"am not longer working on evo". Sharing opinions/ideas is a big
<br>contribution in it-self :) It helps people who contribute through code
<br>to do the right things. just a humble thought.
<br><br><br>- Chenthill.
<br>>
<br><br><br>_______________________________________________
<br>Evolution-hackers mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26463797&i=2" target="_top" rel="nofollow">Evolution-hackers@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-hackers" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-hackers</a><br><p>From forum: <a href="http://old.nabble.com/Gnome---Evolution---Dev-f1298.html" embed="fixTarget[1298]" target="_top" >Gnome - Evolution - Dev</a></p>tag:old.nabble.com,2006:post-26462493Re: Camel Manifesto2009-11-21T19:04:39Z2009-11-21T19:04:39ZMatthew BarnesOn Fri, 2009-11-20 at 14:21 -0500, Jeffrey Stedfast wrote:
<br>> I agree with Michael Meeks' concerns here. I also think there are much
<br>> more important fish to fry which are also far easier to tackle.
<br><br>Sure. I should have been clearer that this is by no means a high
<br>priority task. It will happen gradually, in stages, as time permits.
<br>For now I'm blocked anyway waiting for SSL support to land in GIO. Once
<br>that happens, CamelStreams will be replaced by GIO streams. Existing
<br>providers can continue using synchronous stream operations for awhile
<br>longer, while the parts of Evolution that are already asynchronous or
<br>will soon be transitioning to that won't have to double-buffer streamed
<br>data from Camel any longer.
<br><br>Meanwhile, once the aftershocks from the Bonobo removal are sufficiently
<br>squared away, I'll be turning my attention to the summary database and
<br>other higher priority issues like you mentioned. The GObject transition
<br>will mainly happen in the background, during my off hours.
<br><br>Matthew Barnes
<br><br>_______________________________________________
<br>Evolution-hackers mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462493&i=0" target="_top" rel="nofollow">Evolution-hackers@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-hackers" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-hackers</a><br><p>From forum: <a href="http://old.nabble.com/Gnome---Evolution---Dev-f1298.html" embed="fixTarget[1298]" target="_top" >Gnome - Evolution - Dev</a></p>tag:old.nabble.com,2006:post-26461383Re: Mails in Gmail inbox are in junkbox in Evolution2009-11-21T15:17:58Z2009-11-21T15:17:58ZjreidthompsonWindows To Linux wrote:
<div class='shrinkable-quote'><br>> hi all,
<br>> this drives me crazy and for a few days, i thought i really didnt
<br>> recieve any emails. unable to believe this i signed in to gmail, but
<br>> there were emails in inbox.
<br>> then only it hit me, that all the inbox messages in gmail are stored
<br>> in junk box in evolution.
<br>>
<br>>
<br>> plz help me to solve this problem,
<br>> i really like evolution and don't want to use alternatives.
<br>>
<br>> thank you very much for your help and time.
</div><br>Begin to train Evolution as to what is junk and what is not.
<br>select all the emails in Junk that are not junk and click the 'Not Junk' button.
<br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461383&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26457005Mails in Gmail inbox are in junkbox in Evolution2009-11-21T06:21:32Z2009-11-21T06:21:32ZWindows To Linuxhi all,
<br>this drives me crazy and for a few days, i thought i really didnt
<br>recieve any emails. unable to believe this i signed in to gmail, but
<br>there were emails in inbox.
<br>then only it hit me, that all the inbox messages in gmail are stored
<br>in junk box in evolution.
<br><br><br>plz help me to solve this problem,
<br>i really like evolution and don't want to use alternatives.
<br><br>thank you very much for your help and time.
<br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26457005&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26456005Re: connect Evolution 2.28 to MS exchange 2007 on Fedora 122009-11-21T04:14:05Z2009-11-21T04:14:05ZThomas Novin-5On Thu, 2009-11-19 at 16:42 +1100, L wrote:
<br>> On Thu, Nov 19, 2009 at 3:05 PM, Mail Llists <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26456005&i=0" target="_top" rel="nofollow">lists@...</a>> wrote:
<br>> > On 11/18/2009 10:15 PM, L wrote:
<br>> That's what I have, XP on VirtualBox. but I do hope linux evolution
<br>> will connect to MS exchange via mapi
<br>> Some guys talked about working evolution 2.28 (maybe on ubuntu??)
<br><br>evolution-mapi doesn't work by default on Ubuntu Karmic. However, there
<br>is a PPA that has an updated version (2.28.1) that works. Read comment
<br>#2 on bug
<br><a href="https://bugs.launchpad.net/ubuntu/+source/evolution-mapi/+bug/472552" target="_top" rel="nofollow">https://bugs.launchpad.net/ubuntu/+source/evolution-mapi/+bug/472552</a><br><br>Rgds
<br><br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26456005&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26455066Re: connect Evolution 2.28 to MS exchange 2007 on Fedora 122009-11-21T01:53:03Z2009-11-21T01:53:03ZNg Oon-EeOn Sat, 2009-11-21 at 08:35 +0100, Jean-Claude Tergal wrote:
<div class='shrinkable-quote'><br>> 2009/11/19 L <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26455066&i=0" target="_top" rel="nofollow">yuanlux@...</a>>:
<br>> >>> One of main reasons for upgrade F11 to F12 was to hope to connect
<br>> >>> evolution 2.28 to Exchange 2007. After a smooth upgrade to F12. I
<br>> >>> tried to connect evolution 2.28 with evo-mapi to M$ exchange server.
<br>> >>> no luck at all, it crashed every time. The insttiute's exchange server
<br>> >>> does not open imap port. i you have sucessful connection, please
<br>> >>> share with me
<br>>
<br>> I have a successful connection, but my compagny is using Exchange 2003
<br>> ; and the evolution-exchange RPM of Mandriva 2010 says "Currently,
<br>> only Exchange 2000 and 2003 are supported". So, it seems that Exchange
<br>> 2007 is not supported at all ; I think you have to stay with
<br>> VirtualBox, or use the bloody Outlook Web Access in Firefox.
<br>>
<br>> Nicolas
<br>> Strasbourg (France)
</div><br>I have a successful connection with Exchange 2007. Evo-mapi crashes
<br>immediately in release 2.28.0, you need 2.28.1 where the fixes are. I'm
<br>not familiar with F12 or indeed anything about Fedora, but you may need
<br>to talk to the maintainer of gnome/evolution/evo-mapi for your distro.
<br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26455066&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26454891Re: Camel Manifesto2009-11-21T01:27:29Z2009-11-21T01:27:29ZSankar P-5On Sat, Nov 21, 2009 at 12:51 AM, Jeffrey Stedfast <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26454891&i=0" target="_top" rel="nofollow">fejj@...</a>> wrote:
<div class='shrinkable-quote'><br>> Matthew Barnes wrote:
<br>>> With work on Bonobo removal wrapping up, I've finally started taking a
<br>>> closer look at Camel (Evolution's mail storage and networking library)
<br>>> and laying out plans for where I'd like it to go over the short and long
<br>>> term, with the ultimate goal of splitting it off as a useful standalone
<br>>> GNOME library (but we're a long way from that).
<br>>>
<br>>> As usual I'm taking a bottom-up approach, starting with basic cleanup
<br>>> chores (both code and development policies) and building up from there.
<br>>> Here's some of my thoughts:
<br>>>
<br>>>
<br>>> Backward Compatibility Policy
<br>>> -----------------------------
<br>>>
<br>>> A reverse dependency search in Debian and Fedora reveals the only
<br>>> external projects currently linking to Camel are mail-notification,
<br>>> evolution-jescs and Anjal (please correct me if I've missed any).
<br>>>
<br>>> That tells me that until Camel moves out of its parents' basement and
<br>>> matures into an real, honest-to-goodness library, fixing its interface
<br>>> is more important than maintaining backward compatibility. Deprecation
<br>>> periods for obsolete API are not necessary, in my opinion. The few
<br>>> external projects linking to Camel will just have to keep up with the
<br>>> changes every six months.
<br>>>
<br>>
<br>> I think it's a worthy goal to separate Camel out of Evolution.
<br>>
<br>>> That's not a license to go hog wild though. Some caveats:
<br>>>
<br>>> 1) The soname -must- be kept accurate. If you break the API or ABI,
<br>>> increment the soname when you commit the break. It doesn't matter if
<br>>> the break doesn't affect external projects, nor even if it's already
<br>>> been incremented since the last point release. Bump it anyway.
<br>>> "Always bump" is an easy policy to remember. It makes our own daily
<br>>> development run smoother, and helps ensure a release doesn't slip out
<br>>> with an inaccurate soname.
<br>>>
<br>>> If you're not sure if your patch requires a soname increment, please
<br>>> ask in IRC or Bugzilla. Patch reviewers should try to remember too.
<br>>>
<br>>> 2) If you must break the API, try to do so in a way that things will
<br>>> fail noisily at build time rather than mysteriously at run time. For
<br>>> example, if you want to change the behavior of an existing function,
<br>>> it's better to rename the function or change its parameter list so
<br>>> that stale Evolution code will fail to build.
<br>>>
<br>>> 3) Camel started life as a general purpose mail library and I'd like to
<br>>> try to get back to that. Camel has become too Evolution-centric in
<br>>> my view, with too many quick-fix hacks for Evolution bugs that would
<br>>> not be appropriate for a general purpose mail library. I will clean
<br>>> these up as I find them, but try to keep that in mind when altering
<br>>> the API yourself.
<br>>>
<br>>
<br>> I'm not sure what Evolution-specific quick-fix hacks you mean?
<br>>
<br>>>
<br>>> Migrate to GObject
<br>>> ------------------
<br>>>
<br>>> Camel's homegrown type system will be replaced with GObject so that
<br>>> introspection and D-Bus + language bindings are possible. CamelObject
<br>>> will remain (for now), but as a subclass of GObject. The redundant
<br>>> parts of CamelObject will be removed.
<br>>>
<br>>
<br>> Worthy goals... there are some things like CamelObjectBag and such that
<br>> don't have an equivalent in GObject.
<br>>
<br>>> I'm also following GLib and GTK+'s example of sealing up public instance
<br>>> data in private sections and enforcing that only its top-level header
<br>>> file be included outside of Camel (including the providers). Unlike
<br>>> GLib and GTK+, there will be no transition period.
<br>>>
<br>> Okay.
<br>>
<br>>> This will give us a lot more freedom to reorganize the library and
<br>>> refactor code without disturbing the ABI. Debugging is also easier when
<br>>> you can trap data accesses through "get" and "set" functions.
<br>>>
<br>>
<br>> Sure, but I don't think any code actually goes behind any get/set
<br>> method's back at the moment (or at least didn't back when I worked on
<br>> Camel). Regardless, I'm cool with the proposed changes...
<br>>
<br>>> I've been chipping away at this as a side project for the past year (it
<br>>> was a good mindless activity when I got burned out on Bonobo removal),
<br>>> and I recently published my results to git.gnome.org as a branch named
<br>>> "camel-gobject". The CamelObject conversion is finished -- including
<br>>> all the boilerplate changes in the subclasses -- but I haven't finished
<br>>> sealing up the API.
<br>>>
<br>>> The branch probably won't land until 2.31 at the earliest. The backward
<br>>> compatibility policies I described above would be in effect thereafter.
<br>>>
<br>>>
<br>>> Kill CamelStream
<br>>> ----------------
<br>>>
<br>>> This is a distant future goal and will have to happen gradually, but I
<br>>> would like Camel to shift to a single-threaded design where all file and
<br>>> network operations directly use or are derived from GIO's asynchronous
<br>>> file and stream APIs. SSL support is currently under development for
<br>>> GIO, and that's the only missing piece I see at the platform layer.
<br>>>
<br>>> I realize this is a drastic course correction and will require rewriting
<br>>> all the providers and much of the mailer code in Evolution, but I firmly
<br>>> believe that the overuse of threads carries much of the blame for
<br>>> Evolution's chronic instability over the years and that reversing that
<br>>> trend first and foremost requires minimizing our use of threads for I/O
<br>>> and relying more heavily on GLib's main loop.
<br>>>
<br>>>
<br>>> Comments and constructive criticism encouraged.
<br>>>
<br>>
<br>> I agree with Michael Meeks' concerns here. I also think there are much
<br>> more important fish to fry which are also far easier to tackle.
<br>>
<br>> An IMAP rewrite (which supports IDLE) seems to be something a lot of
<br>> users would be very thankful for, for example. The ancient IMAP code
<br>> that is still being used by default (afaik) is probably one of the
<br>> biggest sources of frustration for both users and maintainers (it also
<br>> has a reputation for being the biggest source of race
<br>> conditions/deadlocks in all of Evolution - which seems to be your
<br>> primary reason for making Camel async ;-)
<br>>
</div><br>I absolutely agree. I am reminded of some of the code comments that
<br>used to exist like: "There are so many broken IMAP servers out there",
<br>"Hack to handle the broken Exchange 2005 IMAP access" etc. Evolution
<br>now has far more providers to support and far less people to work on,
<br>than say two years ago. So, I might actually suggest that we rely on
<br>something like "offlineimap" to do the networking part. Evolution can
<br>then just work on the maildir provided by the mail fetching daemon.
<br>since offlineimap supports signals, you can map "get-mail" events
<br>also. the only problem is that the service will be disconnected and
<br>all mails will be fetched.
<br><br>Though everyone likes to write new code, I am sure it will cause a lot
<br>of maintenance problems with so many providers to support. Camel can
<br>just be mail library that runs as a service and provides a single
<br>point of api for other tools (Tracker/Beagle, OpenOffice, whatever).
<br>Internally it makes use of offlineimap, smtp, GW-MUA for whatever mail
<br>transport.
<br><br>> The sqlite backend stuff could also use some work. As far as I'm aware,
<br>> the tables are non-optimal. At one point I noticed that UIDs (the
<br>> primary key in the table) were stored as strings - it would be better to
<br>> store them as uint32s (yes, I know the gw and exchange backends do not
<br>> use uint32s for UIDs) for performance reasons. It should be possible for
<br>> these backends to have a second table which mapped the canonical uint32
<br>> UID key to the key used by the servers.
<br>>
<br><br>Yes. when Srini and I started with the sqlite summary work, we planned
<br>to implement the basic workflow first and then to improve the database
<br>in more effective ways. But sadly none of us work anymore on
<br>Evolution directly and we weren't aware of these surprises when we
<br>implemented the initial version of sqlite summary.
<br><br>One important area that could improve immensely is Search. We now do a
<br>"Like '<string>'" query on database often leading to slowed search
<br>results. We can create more indices and once the user starts typing in
<br>the text box, we can autocomplete adn do a EXACT Search in teh
<br>database often leading to faster results. For instance, if I search
<br>for Fejj now the query that goes to db is LIKE FEJJ. Whereas, if we
<br>can autocomplete during the search and show <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26454891&i=1" target="_top" rel="nofollow">fejj@...</a>, then in
<br>the database it is faster to search with a EXACT match. this may not
<br>look like a big improvement in theory but I believe it will be a big
<br>usability improvement and can also of be use for other applications
<br>that will rely on us, when camel becomes a service etc. Sadly, I was
<br>never able to make the management understand the need for this when I
<br>was in the team and also we never had the time to complete the
<br>disk-summary migration and other related tasks etc.
<br><div class='shrinkable-quote'><br>> Additionally, the way Camel current works (even now, with the sqlite
<br>> backend), when a folder is opened, the entire summary for the folder is
<br>> loaded the same as it used to be before the sqlite changes. This seems
<br>> rather... wasteful? Kinda defeats the purpose of using sqlite (or any
<br>> other database backend). The main problem with the older format is that
<br>> it did not allow random-access, which means we really needed to load the
<br>> whole thing into memory for a number of reasons:
<br>>
<br>> 1. each record being a different size requires sequential access
<br>> from disk
<br>> 2. can't sort by sender, subject, date (or whatever) until you have
<br>> the entire summary in memory
<br>> 3. doing lookups on message UIDs would be prohibitively slow from disk
<br>>
<br>> With a db backend, none of these problems exist any longer. Some Camel
<br>> APIs would likely need to change in order to support taking advantage of
<br>> this new feature, but it's something that needs to be done.
<br>>
</div><br>IIRC, For showing in message list, we already fetch only whatever
<br>records are needed and do not load the full summary onto the memory.
<br>For instance, if you have selected "Unread mail" in the QuickShow
<br>combo box, only unread mails' summary items are loaded.
<br><br>>
<br>> These things seem like much bigger wins for Camel's (and, by extension,
<br>> Evolution's) usability/maintainability than making Camel async and are
<br>> also far more trivial to implement.
<br>>
<br>> Just some things to think about...
<br>>
<br><br>I tend to agree with Fejj on this and I am big fan of threads. But I
<br>no longer work on evo and knowing Matthew I believe he knows what is
<br>the best. All the best :-)
<br><br>--
<br>Sankar P
<br><a href="http://psankar.blogspot.com" target="_top" rel="nofollow">http://psankar.blogspot.com</a><br>_______________________________________________
<br>Evolution-hackers mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26454891&i=2" target="_top" rel="nofollow">Evolution-hackers@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-hackers" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-hackers</a><br><p>From forum: <a href="http://old.nabble.com/Gnome---Evolution---Dev-f1298.html" embed="fixTarget[1298]" target="_top" >Gnome - Evolution - Dev</a></p>tag:old.nabble.com,2006:post-26454380Re: connect Evolution 2.28 to MS exchange 2007 on Fedora 122009-11-20T23:35:25Z2009-11-20T23:35:25ZJean-Claude Tergal2009/11/19 L <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26454380&i=0" target="_top" rel="nofollow">yuanlux@...</a>>:
<br>>>> One of main reasons for upgrade F11 to F12 was to hope to connect
<br>>>> evolution 2.28 to Exchange 2007. After a smooth upgrade to F12. I
<br>>>> tried to connect evolution 2.28 with evo-mapi to M$ exchange server.
<br>>>> no luck at all, it crashed every time. The insttiute's exchange server
<br>>>> does not open imap port. i you have sucessful connection, please
<br>>>> share with me
<br><br>I have a successful connection, but my compagny is using Exchange 2003
<br>; and the evolution-exchange RPM of Mandriva 2010 says "Currently,
<br>only Exchange 2000 and 2003 are supported". So, it seems that Exchange
<br>2007 is not supported at all ; I think you have to stay with
<br>VirtualBox, or use the bloody Outlook Web Access in Firefox.
<br><br>Nicolas
<br>Strasbourg (France)
<br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26454380&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26472358Re: Cannot empty trash2009-11-20T16:17:26Z2009-11-20T16:17:26ZJohn Ross-7<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
Well,<BR>
I do not wish the developers to take offence, but when one refers to the FAQ and the bug report mentioned therein, it goes back to 2001! Hence my shock-horror and the 'what if this was in the commercial world' scenario. How long is long enough?<BR>
<BR>
In the meantime I have taken to starting evolution from the following script:<BR>
<BR>
#!/bin/bash<BR>
export LANG=C<BR>
#shutdown if running<BR>
evolution --force-shutdown<BR>
for each in index data cmeta; do<BR>
find ~/.evolution/mail/local -type f -iname "*.$each" | xargs rm<BR>
done<BR>
rm ~/.evolution/mail/local/folders.db<BR>
evolution --component=mail <BR>
<BR>
It takes a couple of seconds longer for evolution to start, but I don't mind: it solves the problem.<BR>
<BR>
Though I hesitate to suggest it, since the real fix is apparently so difficult to achieve, perhaps the workaround could be built in to the app, as a 'Delete index files on exit' item in Preferences. At least then users who aren't comfortable at the command line would not have to suffer bloating Trash folders.<BR>
<BR>
John<BR>
<BR>
On Thu, 2009-11-19 at 13:14 -0500, Robert Seward wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Wed, 2009-11-18 at 00:46 +1100, John Ross wrote:
> Let's try a little role-play... You, the developer, have created a GUI
> app that regularly corrupts its own index files. You have been told
> about the bug some time ago and done some research, now you have
> turned up to a meeting with your PM claiming to have fixed it.
>
Yes in this role-playing. Is the "user" a paying customer funding the
"developers" work? If so, maybe this role-playing scenario is valid. If
not, maybe the "user" needs to be patient and let the "developer" fix
the root of the problem not the symptoms of the problem.
I believe Mr Barnes has outlined an approach to fix the root of the
problems. However we must be patient reap the harvest of fruit.
> PM: "OK what's the fix?
> Developer: "The user has to open a terminal and delete all these files
> called ~.xyzblahblah* every time it happens"
> PM: "You're not listening. That's a workaround, not a fix. You can't
> ask GUI users to run around rm'ing things! So when will you have it
> fixed?
> Developer: "But it is fixed."
> PM: "You're still not listening! What agency are you from?"
> Developer: "But... it's easy - all they need to do is..."
> PM: "Look, the files called ~.xyzblahblah* don't even exist in the
> current version, so you don't even have a workaround, let alone a fix.
> What agency?"
> Developer: "But..."
> PM: "FRIDAY, 5pm, no workarounds - a FIX!"
>
> John
Peace,
Rob
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
<br />_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472358&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26472357Suggestions that would make it possible for me to fully migrate to Linux via Evolution2009-11-20T15:36:37Z2009-11-20T15:36:37ZBryan Karlan-2<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><img width=354 height=78 id="Picture_x0020_1" src="http://old.nabble.com/attachment/26472357/0/image002.jpg" alt=AMP.jpg><o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>I am a “power-user” of
Outlook and am interested in fully migrating to Ubuntu and Evolution. I
have tried Outlook with Wine, but that was a waste of time. I push
Outlook to the limits and am hesistant to purchase a $300 copy of a full
install of Windows7 Ultimate and a $500 copy of Office 2010 in 6 months.
I believe that Linux has become a real alternative for a business user and
because of this I have joined your site to offer some advice that would improve
the usability of Evolution.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>I would be interested in being a beta
tester for Outlook migration and Contact Management if at all possible, I think
my extensive use of Outlook makes me an expert on the program. I have
done some very minor programming with it because frankly, while I bought the
book by Sue Mosher on Outlook programming, I found that most of it was not of
worth to me or basically didn’t work. I’ve even confronted
Sue on this several times and was only able to get some programming to work
properly once or twice. I bring this up, just to show you that I know
Outlook, and understand it well.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>I have 15 different contact folders with
over 10,000 contacts. Each window is displayed differently to allow me to
view the data as I feel comfortable with. In the import all the data is
brought into something called CouchDB and into one file. This completely
screws everything up for me to the point of making the import of my contacts
worthless.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>Also, not all the data comes over.
The notes section is fine, but little of the business address and/or mailing
address is imported. Also the Title is missing.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>If I create an address book and import a
CSV file, then I get errors, such as in the notes section I see "Title:
Mr." or "Gender:N/A". I can delete the import of Gender
but I need the Title to come over so that when I mail merge the name is
properly identified. So importing a CSV<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>(windows) doesn't work properly
either. And while CSV brings over much of the mailing info, it deletes
all the notes section and replaces it with the info I stated above. I
used the notes section a lot and that again destroys my data making it
worthless.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>I also have issues with displaying the
data. You have the ability to Group and Sort which is great, but I can't
Group or Sort by the Data I need to do it by. I need to Display the Flag
Status in the File View and to Sort by that first and then by Last Name.
I need to Group by Company and/or Business State or Mailing State. This
info isn't available in the List view to add as a column or to Sort or
Group by.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>I also need to Group by Country, since
in Outlook this is known as Country / Region. I use this to separate
areas of the U.S.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>For example in one folder with over
5,000 contacts, I used Country/Region of Outlook to separate the country into
regions, SOCAL, NOCAL, SE (Southeast), MW (Midwest), NOTX (North Texas),
etc... This info does get imported, howevever I also use the Flag Status
(completed) to show which are the HQ's of the group of businesses (this is
where the mailer gets sent). This is not available on Evolution.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>You probably can't follow everything I'm
saying and this may not be the proper forum to discuss my needs if I'm going to
use this program extensively. You are very close to making this a
replacement for Outlook, but not yet. Who can I talk to in beta testing
to add these abilities?<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>Very Truly Yours,<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><img width=124 height=53 id="Picture_x0020_2" src="http://old.nabble.com/attachment/26472357/1/image004.jpg" alt="Signature, one quarter"><o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>Bryan Karlan<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>President<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>29752 Running Deer<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>Laguna Niguel, CA 92677<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>(949) 363-7625 Office<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>(714) 227-8892 Cell<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472357&i=0" target="_top" rel="nofollow">bkarlan@...</a><o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>or<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472357&i=1" target="_top" rel="nofollow">chunnel@...</a><o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>Website<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:1.0in'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif";color:blue'><a href="http://www.automotivemp.com/" title="http://www.automotivemp.com/" target="_top" rel="nofollow"><span style='color:blue'>www.automotivemp.com</span></a></span><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p></span></p>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>
<br /> <br /> <br />_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472357&i=2" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26450780Re: Backup contacts only2009-11-20T13:45:21Z2009-11-20T13:45:21ZThomas Mittelstaedt-2Am Freitag, den 20.11.2009, 14:37 +0000 schrieb Dianne Reuby:
<br>> Is it possible to backup just my contacts, rather than a full backup?
<br>> (Perhaps by manually copying files to the backup location?)
<br>>
<br><br>Well, and to actually answer you question. Contacts are saved in your
<br>evolution folder in the subdirectory "addressbook":
<br><path_to_your_home>/.evolution/addressbook.
<br><br><br><br><br><br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26450780&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26449445Re: Camel Manifesto2009-11-20T12:01:57Z2009-11-20T12:01:57ZPaul Smith-43On Fri, 2009-11-20 at 14:21 -0500, Jeffrey Stedfast wrote:
<br>> The sqlite backend stuff could also use some work. As far as I'm
<br>> aware, the tables are non-optimal.
<br><br>I really think it would be worthwhile engaging someone who has "SQL
<br>guru" on their resume and asking them for help on this. Maybe just an
<br>informative query to the sqlite mailing list will get some interest and
<br>useful responses.
<br><br>I know just enough SQL to know that I don't know nearly enough to write
<br>a robust, efficient SQL schema. As with security protocols, I like to
<br>leave this to the experts and just plead for their help :-)
<br><br>_______________________________________________
<br>Evolution-hackers mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26449445&i=0" target="_top" rel="nofollow">Evolution-hackers@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-hackers" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-hackers</a><br><p>From forum: <a href="http://old.nabble.com/Gnome---Evolution---Dev-f1298.html" embed="fixTarget[1298]" target="_top" >Gnome - Evolution - Dev</a></p>tag:old.nabble.com,2006:post-26448940Re: Camel Manifesto2009-11-20T11:21:03Z2009-11-20T11:21:03ZJeffrey StedfastMatthew Barnes wrote:
<div class='shrinkable-quote'><br>> With work on Bonobo removal wrapping up, I've finally started taking a
<br>> closer look at Camel (Evolution's mail storage and networking library)
<br>> and laying out plans for where I'd like it to go over the short and long
<br>> term, with the ultimate goal of splitting it off as a useful standalone
<br>> GNOME library (but we're a long way from that).
<br>>
<br>> As usual I'm taking a bottom-up approach, starting with basic cleanup
<br>> chores (both code and development policies) and building up from there.
<br>> Here's some of my thoughts:
<br>>
<br>>
<br>> Backward Compatibility Policy
<br>> -----------------------------
<br>>
<br>> A reverse dependency search in Debian and Fedora reveals the only
<br>> external projects currently linking to Camel are mail-notification,
<br>> evolution-jescs and Anjal (please correct me if I've missed any).
<br>>
<br>> That tells me that until Camel moves out of its parents' basement and
<br>> matures into an real, honest-to-goodness library, fixing its interface
<br>> is more important than maintaining backward compatibility. Deprecation
<br>> periods for obsolete API are not necessary, in my opinion. The few
<br>> external projects linking to Camel will just have to keep up with the
<br>> changes every six months.
<br>>
</div><br>I think it's a worthy goal to separate Camel out of Evolution.
<br><div class='shrinkable-quote'><br>> That's not a license to go hog wild though. Some caveats:
<br>>
<br>> 1) The soname -must- be kept accurate. If you break the API or ABI,
<br>> increment the soname when you commit the break. It doesn't matter if
<br>> the break doesn't affect external projects, nor even if it's already
<br>> been incremented since the last point release. Bump it anyway.
<br>> "Always bump" is an easy policy to remember. It makes our own daily
<br>> development run smoother, and helps ensure a release doesn't slip out
<br>> with an inaccurate soname.
<br>>
<br>> If you're not sure if your patch requires a soname increment, please
<br>> ask in IRC or Bugzilla. Patch reviewers should try to remember too.
<br>>
<br>> 2) If you must break the API, try to do so in a way that things will
<br>> fail noisily at build time rather than mysteriously at run time. For
<br>> example, if you want to change the behavior of an existing function,
<br>> it's better to rename the function or change its parameter list so
<br>> that stale Evolution code will fail to build.
<br>>
<br>> 3) Camel started life as a general purpose mail library and I'd like to
<br>> try to get back to that. Camel has become too Evolution-centric in
<br>> my view, with too many quick-fix hacks for Evolution bugs that would
<br>> not be appropriate for a general purpose mail library. I will clean
<br>> these up as I find them, but try to keep that in mind when altering
<br>> the API yourself.
<br>>
</div><br>I'm not sure what Evolution-specific quick-fix hacks you mean?
<br><br>>
<br>> Migrate to GObject
<br>> ------------------
<br>>
<br>> Camel's homegrown type system will be replaced with GObject so that
<br>> introspection and D-Bus + language bindings are possible. CamelObject
<br>> will remain (for now), but as a subclass of GObject. The redundant
<br>> parts of CamelObject will be removed.
<br>>
<br><br>Worthy goals... there are some things like CamelObjectBag and such that
<br>don't have an equivalent in GObject.
<br><br>> I'm also following GLib and GTK+'s example of sealing up public instance
<br>> data in private sections and enforcing that only its top-level header
<br>> file be included outside of Camel (including the providers). Unlike
<br>> GLib and GTK+, there will be no transition period.
<br>>
<br>Okay.
<br><br>> This will give us a lot more freedom to reorganize the library and
<br>> refactor code without disturbing the ABI. Debugging is also easier when
<br>> you can trap data accesses through "get" and "set" functions.
<br>>
<br><br>Sure, but I don't think any code actually goes behind any get/set
<br>method's back at the moment (or at least didn't back when I worked on
<br>Camel). Regardless, I'm cool with the proposed changes...
<br><div class='shrinkable-quote'><br>> I've been chipping away at this as a side project for the past year (it
<br>> was a good mindless activity when I got burned out on Bonobo removal),
<br>> and I recently published my results to git.gnome.org as a branch named
<br>> "camel-gobject". The CamelObject conversion is finished -- including
<br>> all the boilerplate changes in the subclasses -- but I haven't finished
<br>> sealing up the API.
<br>>
<br>> The branch probably won't land until 2.31 at the earliest. The backward
<br>> compatibility policies I described above would be in effect thereafter.
<br>>
<br>>
<br>> Kill CamelStream
<br>> ----------------
<br>>
<br>> This is a distant future goal and will have to happen gradually, but I
<br>> would like Camel to shift to a single-threaded design where all file and
<br>> network operations directly use or are derived from GIO's asynchronous
<br>> file and stream APIs. SSL support is currently under development for
<br>> GIO, and that's the only missing piece I see at the platform layer.
<br>>
<br>> I realize this is a drastic course correction and will require rewriting
<br>> all the providers and much of the mailer code in Evolution, but I firmly
<br>> believe that the overuse of threads carries much of the blame for
<br>> Evolution's chronic instability over the years and that reversing that
<br>> trend first and foremost requires minimizing our use of threads for I/O
<br>> and relying more heavily on GLib's main loop.
<br>>
<br>>
<br>> Comments and constructive criticism encouraged.
<br>>
</div><br>I agree with Michael Meeks' concerns here. I also think there are much
<br>more important fish to fry which are also far easier to tackle.
<br><br>An IMAP rewrite (which supports IDLE) seems to be something a lot of
<br>users would be very thankful for, for example. The ancient IMAP code
<br>that is still being used by default (afaik) is probably one of the
<br>biggest sources of frustration for both users and maintainers (it also
<br>has a reputation for being the biggest source of race
<br>conditions/deadlocks in all of Evolution - which seems to be your
<br>primary reason for making Camel async ;-)
<br><br>The sqlite backend stuff could also use some work. As far as I'm aware,
<br>the tables are non-optimal. At one point I noticed that UIDs (the
<br>primary key in the table) were stored as strings - it would be better to
<br>store them as uint32s (yes, I know the gw and exchange backends do not
<br>use uint32s for UIDs) for performance reasons. It should be possible for
<br>these backends to have a second table which mapped the canonical uint32
<br>UID key to the key used by the servers.
<br><br>Additionally, the way Camel current works (even now, with the sqlite
<br>backend), when a folder is opened, the entire summary for the folder is
<br>loaded the same as it used to be before the sqlite changes. This seems
<br>rather... wasteful? Kinda defeats the purpose of using sqlite (or any
<br>other database backend). The main problem with the older format is that
<br>it did not allow random-access, which means we really needed to load the
<br>whole thing into memory for a number of reasons:
<br><br> 1. each record being a different size requires sequential access
<br>from disk
<br> 2. can't sort by sender, subject, date (or whatever) until you have
<br>the entire summary in memory
<br> 3. doing lookups on message UIDs would be prohibitively slow from disk
<br><br>With a db backend, none of these problems exist any longer. Some Camel
<br>APIs would likely need to change in order to support taking advantage of
<br>this new feature, but it's something that needs to be done.
<br><br><br>These things seem like much bigger wins for Camel's (and, by extension,
<br>Evolution's) usability/maintainability than making Camel async and are
<br>also far more trivial to implement.
<br><br>Just some things to think about...
<br><br>Jeff
<br><br>_______________________________________________
<br>Evolution-hackers mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26448940&i=0" target="_top" rel="nofollow">Evolution-hackers@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-hackers" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-hackers</a><br><p>From forum: <a href="http://old.nabble.com/Gnome---Evolution---Dev-f1298.html" embed="fixTarget[1298]" target="_top" >Gnome - Evolution - Dev</a></p>tag:old.nabble.com,2006:post-26448340Re: Backup contacts only2009-11-20T10:40:13Z2009-11-20T10:40:13ZSteve Tucknott-2<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.12.3">
</HEAD>
<BODY>
Dianne,<BR>
If you're running with Linux you may want to try rsync - it is a file copier that only copies changes. I tend to use it for all the evolution backups. I don't have a huge .evolution folder (2.7Gb) and it takes a few minutes to back it up (actually I back up my complete 'home' directory).<BR>
The command is explained well in the man pages and you can get rsync for MS if you wanted to backup to a separate PC.<BR>
<BR>
<BR>
On Fri, 2009-11-20 at 14:37 +0000, Dianne Reuby wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Is it possible to backup just my contacts, rather than a full backup?</FONT>
<FONT COLOR="#000000">(Perhaps by manually copying files to the backup location?)</FONT>
<FONT COLOR="#000000">TIA</FONT>
<FONT COLOR="#000000">Dianne</FONT>
<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">Evolution-list mailing list</FONT>
<FONT COLOR="#000000"><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26448340&i=0" target="_top" rel="nofollow">Evolution-list@...</a></FONT>
<FONT COLOR="#000000"><A HREF="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</A></FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
<br />_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26448340&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26447886Re: Backup contacts only, small correction2009-11-20T10:09:19Z2009-11-20T10:09:19ZThomas Mittelstaedt-2If you are actually using the script, modify it to use the evolution
<br>binary on your machine, since I use a custom installation in /opt/evo!!
<br>So, change the line which says:
<br>"/opt/evo/bin/evolution" to just "evolution" or where ever your
<br>evolution binary is.
<br>
<br>Am Freitag, den 20.11.2009, 19:00 +0100 schrieb Thomas Mittelstaedt:
<div class='shrinkable-quote'><br>> Dianne,
<br>>
<br>> Am Freitag, den 20.11.2009, 14:37 +0000 schrieb Dianne Reuby:
<br>> > Is it possible to backup just my contacts, rather than a full backup?
<br>> > (Perhaps by manually copying files to the backup location?)
<br>> >
<br>>
<br>> You are lucky, Dianne. Just a few days ago, I figured it is somewhat
<br>> inefficient to archive the whole .evolution folder to my usb stick every
<br>> day. So I wrote a little script which uses GNU tar to do an incremental
<br>> backup, see below. Of course, it's necessary to do this from a terminal.
<br>> I hope, you are familiar with that.
<br>>
<br>> So first I would do:
<br>>
<br>> mybackup-evolution-increm.sh /media/disk/evolution-0.tar.gz ## 0-level
<br>> backup, i.e. everything
<br>> next time:
<br>> mybackup-evolution-increm.sh /media/disk/evolution-1.tar.gz ## level-1
<br>> mybackup-evolution-increm.sh /media/disk/evolution-2.tar.gz ## level-2
<br>> ... and so on
<br>>
<br>> ########################################################
<br>> ### Do incremental backups of your .evolution folder
<br>> #! /bin/bash
<br>>
<br>> echo "Shutting down evolution"
<br>> /opt/evo/bin/evolution --force-shutdown
<br>>
<br>> echo "Backing up gnome configuration for /apps/evolution"
<br>> gconftool-2 --dump /apps/evolution
<br>> > /home/tom/.evolution/backup-restore-gconf.xml
<br>>
<br>> echo "Creating incremental backup"
<br>> if [ -f "$1" ] ; then echo "File exists, please choose different
<br>> name" ; exit 1; fi
<br>> cd $HOME && tar chf - .evolution -g .tar-g-evolution | gzip > $1
<br>>
<br>> ########################################################
<br>>
<br>> See also:
<br>> <a href="http://www.gnu.org/software/tar/manual/html_section/Incremental-Dumps.html" target="_top" rel="nofollow">http://www.gnu.org/software/tar/manual/html_section/Incremental-Dumps.html</a><br>>
<br>>
<br>>
</div><br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26447886&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26447726Re: Backup contacts only2009-11-20T10:00:03Z2009-11-20T10:00:03ZThomas Mittelstaedt-2Dianne,
<br><br>Am Freitag, den 20.11.2009, 14:37 +0000 schrieb Dianne Reuby:
<br>> Is it possible to backup just my contacts, rather than a full backup?
<br>> (Perhaps by manually copying files to the backup location?)
<br>>
<br><br>You are lucky, Dianne. Just a few days ago, I figured it is somewhat
<br>inefficient to archive the whole .evolution folder to my usb stick every
<br>day. So I wrote a little script which uses GNU tar to do an incremental
<br>backup, see below. Of course, it's necessary to do this from a terminal.
<br>I hope, you are familiar with that.
<br><br>So first I would do:
<br><br>mybackup-evolution-increm.sh /media/disk/evolution-0.tar.gz ## 0-level
<br>backup, i.e. everything
<br>next time:
<br>mybackup-evolution-increm.sh /media/disk/evolution-1.tar.gz ## level-1
<br>mybackup-evolution-increm.sh /media/disk/evolution-2.tar.gz ## level-2
<br>... and so on
<br><br>########################################################
<br>### Do incremental backups of your .evolution folder
<br>#! /bin/bash
<br><br>echo "Shutting down evolution"
<br>/opt/evo/bin/evolution --force-shutdown
<br><br>echo "Backing up gnome configuration for /apps/evolution"
<br>gconftool-2 --dump /apps/evolution
<br>> /home/tom/.evolution/backup-restore-gconf.xml
<br><br>echo "Creating incremental backup"
<br>if [ -f "$1" ] ; then echo "File exists, please choose different
<br>name" ; exit 1; fi
<br>cd $HOME && tar chf - .evolution -g .tar-g-evolution | gzip > $1
<br><br>########################################################
<br><br>See also:
<br><a href="http://www.gnu.org/software/tar/manual/html_section/Incremental-Dumps.html" target="_top" rel="nofollow">http://www.gnu.org/software/tar/manual/html_section/Incremental-Dumps.html</a><br><br><br><br>--
<br>thomas
<br><br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26447726&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26445504Re: Camel Manifesto2009-11-20T07:46:49Z2009-11-20T07:46:49ZMatthew BarnesOn Fri, 2009-11-20 at 10:36 +0000, Michael Meeks wrote:
<br>> Hmm; you really propose to remove all threading from camel's
<br>> implementation ? or just from it's API ? a full removal might be
<br>> problematic.
<br><br>There may be isolated cases internally to Camel where it can exploit
<br>parallelism in CPU-intensive tasks with threading or where threads are
<br>necessary for interacting with synchronous-only libraries, but it should
<br>be used sparingly and hidden behind a fully asynchronous API. It should
<br>not be central to the design of the entire mail application, as it is
<br>currently. Basically I want the mail front-end in Evolution 3 to be
<br>single threaded, or as close to that as possible.
<br><br>My motivation for the manifesto stems from two sources:
<br><br>The first is what I think is a very insightful paper on the inherent
<br>problems with threads:
<br><a href="http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf" target="_top" rel="nofollow">http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf</a><br><br>The second is Peter William's design document on Camel, which has been
<br>sitting in our source tree for nearly a decade:
<br><a href="http://git.gnome.org/cgit/evolution/tree/mail/README.async" target="_top" rel="nofollow">http://git.gnome.org/cgit/evolution/tree/mail/README.async</a><br><br>Setting aside the outdated implementation details he talks about, it's
<br>clear that many of Camel's early design decisions that were made during
<br>the 1.x era (or perhaps earlier?) are essentially still in place today.
<br><br>Reading through that document now, the rationale just doesn't stand up
<br>anymore, in my opinion. CamelObject should have been killed off long
<br>ago, and the arrival of GIO and now GNIO totally changes the game for
<br>us. Peter even hints at -- as what was then a distant future goal --
<br>basically what I'm proposing now, here in the distant future.
<br><br>Standing on the cusp of a new era for GNOME, I feel like the time is
<br>right to reevaluate what's working and what's not and at least -attempt-
<br>a course correction. I think an asynchronous design that takes full
<br>advantage of our increasingly capable platform libraries is the way
<br>forward.
<br><br>I just don't want to spend the duration of GNOME 3 struggling with the
<br>same tired old issues that we struggled with for much of GNOME 2. The
<br>community's patience is wearing thin and so is mine.
<br><br>Matthew Barnes
<br><br>_______________________________________________
<br>Evolution-hackers mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26445504&i=0" target="_top" rel="nofollow">Evolution-hackers@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-hackers" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-hackers</a><br><p>From forum: <a href="http://old.nabble.com/Gnome---Evolution---Dev-f1298.html" embed="fixTarget[1298]" target="_top" >Gnome - Evolution - Dev</a></p>tag:old.nabble.com,2006:post-26444969Evolution and Exchange 2010 Archive Feature2009-11-20T07:12:43Z2009-11-20T07:12:43ZSPST SPST<div>Hi,</div>
<div> </div>
<div>I'm new in the mailing-list of evolution, I work as Enterprise Messaging as a role of support organization (in a direction in a french ministery). We will migrate to Exchange 2010. (In order to deploy the archive feature).</div>
<div> </div>
<div>I'm not "source code-friendly" with the product Evolution but i 've read, roughly speaking, that Evolution uses web-services of Microsoft and Webdav for the Exchange Connector. We have been told to make a studie on different messaging client and especially one of them is Evolution.</div>
<div> </div>
<div>Could you help me to answer some questions :</div>
<div> - Where to find a technical documentation on how Evolution work, generally and specially with Exchange.</div>
<div> - Will Evolution work with Exchange 2010 (Microsoft announced that Webdav will slowly disapear in the profit of Exchange Webservices)</div>
<div> - Do you know, if in the future version, Evolution will interface with the archive feature or the archive feature will remain only to Mcrosoft ? </div>
<div> </div>
<div>Eventually, could you give me some news, contacts, resources to know more about Evolution and Exchange 2010, I know it's a bit early to answer some of my questions but deploying Evolution in a part of french government could be a good advertise for your product!! </div>
<div> </div>
<div>Thanks a lot.</div>
<div> </div>
<div>Alexis.</div>
<div> </div>
<div>PS : Sorry for my english</div>
<br />_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26444969&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26444299Backup contacts only2009-11-20T06:37:36Z2009-11-20T06:37:36ZDianne ReubyIs it possible to backup just my contacts, rather than a full backup?
<br>(Perhaps by manually copying files to the backup location?)
<br><br><br>TIA
<br>Dianne
<br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26444299&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26441194Re: Camel Manifesto2009-11-20T02:36:40Z2009-11-20T02:36:40Zmichael meeksHi Matthew,
<br><br>On Wed, 2009-11-18 at 14:07 -0500, Matthew Barnes wrote:
<br>> With work on Bonobo removal wrapping up, I've finally started taking a
<br>> closer look at Camel (Evolution's mail storage and networking library)
<br><br> Ah - another life-time of cleaning up, and polishing code: the goal
<br>sounds really nice.
<br><br>> This is a distant future goal and will have to happen gradually, but I
<br>> would like Camel to shift to a single-threaded design where all file and
<br>> network operations directly use or are derived from GIO's asynchronous
<br>> file and stream APIs.
<br><br> Hmm; you really propose to remove all threading from camel's
<br>implementation ? or just from it's API ? a full removal might be
<br>problematic.
<br><br> While clearly threading, if done in an un-constrained way, has it's own
<br>peculiar problems - there are a couple of obvious advantages:
<br><br> First debugging - while both async and threaded programming loose
<br>determinism due to event re-ordering - the debugger at least understands
<br>threads - and can hopefully show you your state in a reasonably
<br>follow-able way - you can step through slow/blocking calls with 'next',
<br>'finish' etc.; I worry about a world packed with highly granular
<br>asynchronous state-machines, all chained together - with no good way to
<br>see what is happening, what state everything is in, and (of course) why
<br>the app is serenely inactive in it's mainloop suddenly ;-)
<br><br> Secondly - of course, a fully async mode potentially would loose any
<br>(possible) benefit of parallelism that in theory threads can provide -
<br>in this world of dual-core laptop CPUs, and even hyper-threaded Atoms.
<br><br> OTOH - I'm sure you know what you're doing ;-)
<br><br> ATB,
<br><br> Michael.
<br><br>--
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26441194&i=0" target="_top" rel="nofollow">michael.meeks@...</a> <><, Pseudo Engineer, itinerant idiot
<br><br>_______________________________________________
<br>Evolution-hackers mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26441194&i=1" target="_top" rel="nofollow">Evolution-hackers@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-hackers" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-hackers</a><br><p>From forum: <a href="http://old.nabble.com/Gnome---Evolution---Dev-f1298.html" embed="fixTarget[1298]" target="_top" >Gnome - Evolution - Dev</a></p>tag:old.nabble.com,2006:post-26440117Re: How to hide IMAP folders and force custom view?2009-11-20T00:49:45Z2009-11-20T00:49:45ZMilan CrhaOn Thu, 2009-11-19 at 20:10 +0100, skx skxinski wrote:
<br>> I have two small problems with Evolution UI that I can't solve:
<br>>
<br>> 1. How to force custom view for all folders?
<br>> How to make my custom view (View -> Current Views -> Define View) a
<br>> default one for all folders local or in IMAP accounts unless I
<br>> explicitly select a different one?
<br><br> Hi,
<br>the default view is Messages for most of the folders. What you can do is
<br>to either save your custom view (customized in one folder) as Messages
<br>and then all folders will be shown the same, or you can save your view
<br>as a new one and select that view in all your folders (View->Current
<br>View-><your view>). Maybe you consider it a pain, especially for many
<br>folders, but note you will do that only once (until you change your view
<br>in that folder and will not save it).
<br><br>> 2. How to hide selected folders?
<br>> When selecting subscription folders (Folder -> Subscriptions...) the
<br>> deselected ones are hidden from the folder pane, which is a very nice
<br>> feature. Unfortunately after restarting Evolution they are being shown
<br>> again and clutter this pane. How to hide folders in IMAP accounts, or
<br>> just any folders?
<br><br>You probably have it, but check if Edit->Preferences->Mail
<br>Accounts-><imap account>->Edit->"Receiving Options" tab, option "Show
<br>only subscribed folders" is checked. But as Adam noted in the other
<br>mail, server can influence this, it can force the folder subscription on
<br>its own (it can deny unsubscribe, thus next start, when evolution checks
<br>for a new folders, it is told the folder is subscribed).
<br> Bye,
<br> Milan
<br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26440117&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26432289Re: How to hide IMAP folders and force custom view?2009-11-19T11:11:24Z2009-11-19T11:11:24ZAdam Tauno Williams-5> 2. How to hide selected folders?
<br>> When selecting subscription folders (Folder -> Subscriptions...) the
<br>> deselected ones are hidden from the folder pane, which is a very nice
<br>> feature. Unfortunately after restarting Evolution they are being shown
<br>> again and clutter this pane. How to hide folders in IMAP accounts, or
<br>> just any folders?
<br><br>Not certain about the intent - why not just deny list access to the
<br>folders? [server side, assuming your IMAP server supports folder
<br>permissions]
<br><br>--
<br>OpenGroupware developer: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26432289&i=0" target="_top" rel="nofollow">awilliam@...</a>
<br><<a href="http://whitemiceconsulting.blogspot.com/" target="_top" rel="nofollow">http://whitemiceconsulting.blogspot.com/</a>>
<br>OpenGroupare & Cyrus IMAPd documenation @
<br><<a href="http://docs.opengroupware.org/Members/whitemice/wmogag/file_view" target="_top" rel="nofollow">http://docs.opengroupware.org/Members/whitemice/wmogag/file_view</a>>
<br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26432289&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26432246How to hide IMAP folders and force custom view?2009-11-19T11:10:36Z2009-11-19T11:10:36ZskxplI have two small problems with Evolution UI that I can't solve:
<br><br>1. How to force custom view for all folders?
<br>How to make my custom view (View -> Current Views -> Define View) a
<br>default one for all folders local or in IMAP accounts unless I
<br>explicitly select a different one?
<br><br>2. How to hide selected folders?
<br>When selecting subscription folders (Folder -> Subscriptions...) the
<br>deselected ones are hidden from the folder pane, which is a very nice
<br>feature. Unfortunately after restarting Evolution they are being shown
<br>again and clutter this pane. How to hide folders in IMAP accounts, or
<br>just any folders?
<br><br><br>--
<br>skx.
<br><br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26432246&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>tag:old.nabble.com,2006:post-26431369Re: Search function / indexing not working?2009-11-19T10:20:18Z2009-11-19T10:20:18Zjim ruxtonOn Thu, 2009-11-19 at 11:51 -0500, jim wrote:
<div class='shrinkable-quote'><br>> On Thu, 2009-11-19 at 16:34 +0000, Pete Biggs wrote:
<br>> > On Thu, 2009-11-19 at 11:06 -0500, jim wrote:
<br>> > > On Wed, 2009-11-18 at 12:10 -0500, jim wrote:
<br>> > > > > Hi,
<br>> > > > > I'm on KUbuntu 9.04 and using Evo. 2.26 . For some reason my search
<br>> > > > > function in Evo. is not working properly. If I type in a name from whom
<br>> > > > > I want to see emails I get a whole bunch of other emails that have no
<br>> > > > > resemblance to the search term or name I entered. IT works ok on my Sent
<br>> > > > > folder, just not Inbox. For a day after I updated my system it was
<br>> > > > > working fine again then went haywire . Also sometimes when I am
<br>> > > > > downloading email it locks up and I have to cancel the download and
<br>> > > > > start again. I know in the past there was a problem going over 2 GB with
<br>> > > > > a message folder is that still the case? I tried moving some messages
<br>> > > > > from my Inbox folder to another folder but for some reason the size
<br>> > > > > didn't seem to change even after expunging ? Any suggestions how to fix
<br>> > > > > my system.
<br>> > > > > Thanks
<br>> > > > > JIm
<br>> > > > I fixed this by deleting my Inbox.ibex.index file.
<br>> > > > Jim
<br>> > >
<br>> > > Actually this didn't work for long. I also tried deleting other Inbox.*
<br>> > > files. Everything was good for a while. I think it may be after I closed
<br>> > > Evo. and started it again that it stopped working. Seems like indexing
<br>> > > keeps getting corrupted. Any thoughts as to what is going on?
<br>> >
<br>> > Did you shutdown Evo fully using 'evolution --force-shutdown' before
<br>> > deleting the indexes? If you didn't, you should do.
<br>> Hmm I did when I just deleted the Inbox.ibex.index file but I don't
<br>> think I did when I deleted the other files. I'll try again. Thanks for
<br>> the suggestion.
<br>> Jim
</div><br>I found that I had to delete folders.db as well. Now everything seems to
<br>work. Thanks again for the help.
<br>Jim
<div class='shrinkable-quote'><br>> >
<br>> > P.
<br>> >
<br>> > _______________________________________________
<br>> > Evolution-list mailing list
<br>> > <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26431369&i=0" target="_top" rel="nofollow">Evolution-list@...</a>
<br>> > <a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br>> >
<br>>
<br>>
<br>> _______________________________________________
<br>> Evolution-list mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26431369&i=1" target="_top" rel="nofollow">Evolution-list@...</a>
<br>> <a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br>>
</div><br><br>_______________________________________________
<br>Evolution-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26431369&i=2" target="_top" rel="nofollow">Evolution-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/evolution-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/evolution-list</a><br><p>From forum: <a href="http://old.nabble.com/Gnome-Evolution---General-f2984.html" embed="fixTarget[2984]" target="_top" >Gnome Evolution - General</a></p>