Re: [Evolution-hackers] The recent camel-lite improvements

2007-02-15 Thread Philip Van Hoof
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


[Evolution-hackers] The recent camel-lite improvements

2007-02-07 Thread Philip Van Hoof
I'm of course planning to get this stuff upstream. But I have to warn
the dreamers.

A lot of it is/was done as a hack. That's because I envision that
someday I actually will switch from using Camel to most likely fejj's
libspruce. 

With Camel this was for the last feature, IDLE support, almost undoable
too. That's because I needed non-blocking read support from the
CamelStream types. That change went all the way through a lot Camel
layers to the camel-file-utils and the three TCP implementations (raw,
ssl and openssl).

In other words: a total new design is yet again needed. Eventually I
rather see libspruce fill in that gap, than Camel.

I have no idea if the Evolution team is interested in the features and
changes. But I hereby offer my help to bring them upstream.

But please note that I will not do it 'automatically' myself anymore.

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

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.


ps. I indeed also posted this comment to give the angry anti-fork people
of our great and knowledgeable community anti-flamewar food.


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


Re: [Evolution-hackers] The recent camel-lite improvements

2007-02-07 Thread Veerapuram Varadhan
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

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

2007-02-07 Thread Gilles Dartiguelongue
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