Comments on: Re: Camel-lite http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/ My personal weblog on my work in GNOME Mon, 05 Apr 2010 19:28:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Phenomena in the days of Philip » Blog Archive » From the dark corners of being on holiday … http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/comment-page-1/#comment-222 Phenomena in the days of Philip » Blog Archive » From the dark corners of being on holiday … Tue, 28 Aug 2007 20:46:01 +0000 http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/#comment-222 [...] blog spurred some controversy about Evolution and the adapted Camel that Tinymail internally [...] [...] blog spurred some controversy about Evolution and the adapted Camel that Tinymail internally [...]

]]> By: sragavan http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/comment-page-1/#comment-221 sragavan Tue, 28 Aug 2007 19:13:03 +0000 http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/#comment-221 XAV, an F5 should sync it anyway. But a timely sync or a sized sync is a nice thought. Ill add this to the next camel discussion. XAV, an F5 should sync it anyway. But a timely sync or a sized sync is a nice thought. Ill add this to the next camel discussion.

]]> By: Xav http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/comment-page-1/#comment-220 Xav Tue, 28 Aug 2007 14:14:29 +0000 http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/#comment-220 Hi Srag, I understand the need to delay sync to optimize packet sizes, but IMO Evo shouldn't wait that much to sync (and potentially loose that data). For example, it should fire sync as soon as it has >100 changes to commit, or if it has at least 1 change more than 10s old. Thanks for working on the 1st point ! Xav Hi Srag,

I understand the need to delay sync to optimize packet sizes, but IMO Evo shouldn’t wait that much to sync (and potentially loose that data). For example, it should fire sync as soon as it has >100 changes to commit, or if it has at least 1 change more than 10s old.

Thanks for working on the 1st point !

Xav

]]> By: pvanhoof http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/comment-page-1/#comment-219 pvanhoof Tue, 28 Aug 2007 10:29:08 +0000 http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/#comment-219 Hey Xav and sragavan: This is an improvement that can be ported from Tinymail's camel-lite to camel. Tinymail already supports and does this. Sragavan: it uses the "folder-changed" signal on CamelFolder for this, in the typical Camel way of working. It's mostly about moving the signal emission a bit lower-level in the IMAP code and fixing up some locking issues in CamelFolderSummary that could deadlock during the emission of the signal. It's right that the references header is not fetched at this moment. I'm also taking a look at some solutions for this. The biggest problem at this moment is the amount of pointers needed (each are four bytes) by Evolution for storing each and every reference. I think this can be done better in Evolution too (although for Evolution, that kind of memory savings are overkill). On bandwidth it's going to be hard to reduce bandwidth on reference-info. Although if the user is not sorting threaded, there's also not really any need to retrieve this information (for example a late fetch of that info could be utilized here). Hey Xav and sragavan: This is an improvement that can be ported from Tinymail’s camel-lite to camel. Tinymail already supports and does this. Sragavan: it uses the “folder-changed” signal on CamelFolder for this, in the typical Camel way of working. It’s mostly about moving the signal emission a bit lower-level in the IMAP code and fixing up some locking issues in CamelFolderSummary that could deadlock during the emission of the signal.

It’s right that the references header is not fetched at this moment. I’m also taking a look at some solutions for this. The biggest problem at this moment is the amount of pointers needed (each are four bytes) by Evolution for storing each and every reference. I think this can be done better in Evolution too (although for Evolution, that kind of memory savings are overkill).

On bandwidth it’s going to be hard to reduce bandwidth on reference-info. Although if the user is not sorting threaded, there’s also not really any need to retrieve this information (for example a late fetch of that info could be utilized here).

]]> By: sragavan http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/comment-page-1/#comment-218 sragavan Tue, 28 Aug 2007 10:00:12 +0000 http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/#comment-218 XAV, The first point is one of the theme for 2.14 in my current planning. You should be seeing a much better Evolution in 2.14. On your second point on deferring synching until folder switch is done so as to optimize the network usage by reducing small packets. XAV, The first point is one of the theme for 2.14 in my current planning. You should be seeing a much better Evolution in 2.14. On your second point on deferring synching until folder switch is done so as to optimize the network usage by reducing small packets.

]]> By: Xav http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/comment-page-1/#comment-216 Xav Tue, 28 Aug 2007 08:07:14 +0000 http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/#comment-216 Yeah right. But still Evo is light-years behind Thunderbird in terms of IMAP performance: when connecting to the server Thunderbird starts to fetch headers, the messages are added 1 by 1 to the "headers view" but the UI is still responsive, you can even read a message before having downloaded all headers. And when you do something that changes a state, it's propagated to the server in short time. Contrast this with Evo: when connecting to the server, all IMAP traffix is blocked waiting for ALL headers to download. And then, changes are set back to the server only on Evo quitting of changing folders, which means if you work a lot in one folder and you loose your connection to the server, all your changes are lost. I know this post wasn't about Evo vs Thunderbird, but those problems are years old and I had to rant. Sorry. Yeah right. But still Evo is light-years behind Thunderbird in terms of IMAP performance: when connecting to the server Thunderbird starts to fetch headers, the messages are added 1 by 1 to the “headers view” but the UI is still responsive, you can even read a message before having downloaded all headers. And when you do something that changes a state, it’s propagated to the server in short time.

Contrast this with Evo: when connecting to the server, all IMAP traffix is blocked waiting for ALL headers to download. And then, changes are set back to the server only on Evo quitting of changing folders, which means if you work a lot in one folder and you loose your connection to the server, all your changes are lost.

I know this post wasn’t about Evo vs Thunderbird, but those problems are years old and I had to rant. Sorry.

]]> By: sragavan http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/comment-page-1/#comment-215 sragavan Tue, 28 Aug 2007 07:49:50 +0000 http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/#comment-215 For example, camel-lite fetches a very few headers from the server. One of the most important things that is not fetched and is huge is message-thread header. Unless this header is present in a message, it is impossible to form message threads. It is right with camel-lite not to fetch that header as on a mobile device, it is too much to expect. But not right in case of a Desktop. For example, camel-lite fetches a very few headers from the server. One of the most important things that is not fetched and is huge is message-thread header. Unless this header is present in a message, it is impossible to form message threads. It is right with camel-lite not to fetch that header as on a mobile device, it is too much to expect. But not right in case of a Desktop.

]]> By: koen http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/comment-page-1/#comment-214 koen Tue, 28 Aug 2007 06:35:59 +0000 http://blogs.gnome.org/sragavan/2007/08/28/re-camel-lite/#comment-214 How does switching from camel to camel-lite break threading in evolution? Or are you saying evolution doesn't support threading? How does switching from camel to camel-lite break threading in evolution? Or are you saying evolution doesn’t support threading?

]]>