[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: PATCH: Asynchronous filtering
From:       Till Adam <adam () kde ! org>
Date:       2003-10-28 13:03:09
[Download RAW message or body]

On Tuesday 28 October 2003 10:10, Andreas Gungl wrote:
> Am Montag, 27. Oktober 2003 21:58 schrieb Ingo Klöcker:
> > On Monday 27 October 2003 20:16, Marc Mutz wrote:
> > > On Sunday 26 October 2003 21:27, Till Adam wrote:

[snip]

> I doubt that the KMail users are interested whether threads or processes
> are used to keep the GUI non-blocking. They only don't want it to block.
> Implementations using threads or processes imply nearly the same problems,
> it's almost like a matter of taste. If you can show benefits of the process
> solution, than it should be no problem to switch to that if I understood
> Ingo correctly. Until then I would rather use Till's solution than none.
> ;-)

I would like to point out that most of the work of making the filtering async 
is _not_ in making the pipe through action use the threadweaver, which I did, 
but in making the filter scheduler work in an asynchronous manner, which was 
implemented by Don with only supplementary input from me. Whether we use a 
process or a thread for executing the pipe through action, that work is the 
real issue and the hard part. 

This whole discussion about the debatable merits of using threads for this 
covers the real issue, which is that we need an async filter manager to solve 
the problem of gui blocking and also make optional body downloading of imap 
mails possible in the future. 

Don and I have talked and agree that we should probably not include the new 
actionscheduler (the asyc filter manager) in the 3.2 release, as much as that 
will dissappoint some people. It is an invasive change which has not have 
enough time to mature. We both feel bad about rushing this change. Stability 
should come first. We'll target the mythical standalone pim release in a few 
months with this. KMail will have to live with its number one bug a little 
while longer. ;) The relevant fles are in cvs now, but not hooked in, so we 
can continue working on it in cvs. I'll post an updated patch against head 
later today.

> Regarding your request for some kind of roadmap for KMail, I also think
> that it would be good to define some goals before cvs is open for new
> features again. You're right that some refactoring is needed and that the
> programmers would benefit from that after all. New features are good for
> the users, refactoring is good for the programmers. It's just a question of
> the balance. I'm really interested how you core developers will solve this
> conflict.

I agree with the roadmap idea.

Till
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]