Re: [Evolution-hackers] The recent camel-lite improvements
On Wed, 2007-02-07 at 21:40 +0100, Gilles Dartiguelongue wrote: It'd be nice to see the work for IDLE make it to mainline too. I would like to warn that the work for IDLE pulls nearly each and every change to the IMAP code with it, as a dependency. The IDLE work requires changes to dealing with expunges, changes to the camelstream type (it needs non-blocked reading, and with the current design of Camel there's also no other way to read the IDLE responses correctly), changes to the imap-command type and really significant changes to the locking of the IMAP provider's connection. It also enjoys the condstore support, a lot. As well as that it enjoys the rewrite of the imap_update_summary implementation. That's mostly because the index of each summary item must be exactly correct with the sequence on the IMAP mailbox. Imagine that not being in sync and a push happening on that sequence. A push like an expunge or a flags-update: the wrong message would be changed locally. That would be like a bug that the user experiences as data loss. So it really really has to be absolutely correct. This is also why extra checking has been put in place in both imap_summary_update, imap_rescan and the new imap_rescan_condstore implementation: it *HAS* to be correct As a developer myself, I'm totally pro pushing the changes to Evolu- tion's Mailer component. You would indeed have instant changes and even eventually incrementally filling up the folder-view while you are downloading the folder(this is possible, yes. Like Polymer .. yes). But from a stability point of view, it *would* most likely destabilize the product ... Evolution at this moment. And that is must likely not interesting for Novell. Am I wrong or right about this feeling of mine ? :-) I would, however, aid the person that gets my work into a RD branch of Evolution or whatever. Evolution, however, isn't *my* focus project. And this would consume my entire own focus. I will help the person who makes it his project. That's what these notes are about. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] The recent camel-lite improvements
On Wed, 2007-02-07 at 11:36 +0100, Philip Van Hoof wrote: [snip...] The very simple reason is lack of interest. Whenever I posted a patch in the past, it took months before somebody even touched the status of the bug, commented on it or even took a look at it. This has nothing to do with time anymore, as far as I can see (weeks, okay. But months?) Which is absolutely not my problem, nor should I condemn that or whatever nor am I trying to make a statement other than: well then, I'm also not going to loose *my* time with that. I guess that sounds fair, or doesn't it? (I have to note, though, that fejj very recently commented on some of the patches, for which I'm grateful and I have been taking into account his comments and will improve the stuff he mentioned soon). Fejj is a long time contributor to Evolution and he is no different from any evolution developers and a nod from him would be a good validation point for Mailer hackers to work with you and get your work upstream. Of all those features/implementations that you have mentioned so far, I could list 2 of them fit the interest of evolution - mmap (without summary format changes - adding len is okay) and memory-optimization in using tokens in camel-folder-summary.c. Rest of them are too focused and don't provide abstractions to extend for a desktop application. Also, I am still on the assumption that you are getting your mmap work committed to the mmap-branch, which would be validated and taken during the next development cycle and I am yet to see any updates on that. Although I *AM* actively going to help the person who will port this stuff to Evolution's Camel. By that I mean that I *will* make time for this person. A lot if necessary. Entire evenings of free time if I have to. It's not so much about *time* itself, it's 100% about loosing it on something that wont be acted upon anyway. Nobody enjoys that, I certainly don't. We appreciate that and looking forward to get the good work merged soon. V. Varadhan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] The recent camel-lite improvements
On Wed, 2007-02-07 at 08:58 -0700, Veerapuram Varadhan wrote: On Wed, 2007-02-07 at 11:36 +0100, Philip Van Hoof wrote: Of all those features/implementations that you have mentioned so far, I could list 2 of them fit the interest of evolution - mmap (without summary format changes - adding len is okay) and memory-optimization in using tokens in camel-folder-summary.c. Rest of them are too focused and don't provide abstractions to extend for a desktop application. I agree that most of the changes are indeed focused on mobile uses. I mentioned the changes in the E-mail because there are some people who privately and on IRC urge me to synchronize as much as possible of the work with Evolution's Mailer code. While I don't disagree with them, I too feel that it's up to the Mailer maintainers -and people to decide about this. I share your opinion that most of the changes are not focused on desktop applications. Also, I am still on the assumption that you are getting your mmap work committed to the mmap-branch, which would be validated and taken during the next development cycle and I am yet to see any updates on that. I wrote this down, and will take a look at what I can extract from the current camel-lite version into the current Camel version of Evolution. If somebody wants to speed this up, assistance is welcomed :) Note though that I'm planning to implement a very different idea on the summary work. Something with mmap()ed segments (multiple summary files per folder, on the disk) of 1,000 summary items per segment and putting the flags in a separate file. Might sound a little bit overkill too. So I might withdraw from the idea too. It's just that I have certain performance issues when locally searching, that could more easily be solved this way. Although I *AM* actively going to help the person who will port this stuff to Evolution's Camel. By that I mean that I *will* make time for this person. A lot if necessary. Entire evenings of free time if I have to. It's not so much about *time* itself, it's 100% about loosing it on something that wont be acted upon anyway. Nobody enjoys that, I certainly don't. We appreciate that and looking forward to get the good work merged soon. Thanks. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] The recent camel-lite improvements
It'd be nice to see the work for IDLE make it to mainline too. -- Gilles Dartiguelongue [EMAIL PROTECTED] ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
