Evolution’s goals (camel) are definitely different from Tinymail’s goal (camel-lite). You definitely can’t substitute each other in all places. Users wont be happy to use a email client that doesn’t even support message threading on a desktop. Philip posted an overview camel-lite onto the evolution-hackers list some time back. Camel-lite has a lot of things that can be merged with upstream camel like pop summary, some IMAP improvements (non-hacky stuffs). I’m sure that the discussion is ON between Varadhan and Philip to get the pop summary into trunk for early 2.14 cycle and more merging of useful things down the time. But I won’t / don’t think Evolution would move away from camel to camel-lite any time.
Update: I just saw that Sankar (who maintains EPlugins) has posted a nice blog about Evolution/Camel/Camel-lite. Though I don’t agree to all the points, some interesting differences and goals.
How does switching from camel to camel-lite break threading in evolution? Or are you saying evolution doesn’t support threading?
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.
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.
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.
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).
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
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.