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

List:       kmail-devel
Subject:    Re: PATCH: Asynchronous filtering
From:       Andreas Gungl <Andreas.Gungl () osp-dd ! de>
Date:       2003-10-28 9:10:18
[Download RAW message or body]

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:
> > > Be my guest. :) No one has implemented the solutions you propose,
> > > although they are of course perfectly doable. The weaver is a very
> > > straight forward way to encapsulate tasks that would otherwise
> > > block the gui and be notified when they are done. It might not be
> > > the most efficient way to do it, but it's simple and works. It
> > > abstracts away a lot of the unpleasantness of dealing with
> > > asyncronous jobs. Feel free to provide us and the rest of kde with
> > > a similarly straight forward implementation of that using
> > > processes.
> >
> > Come on, you don't want to sell me threads as being easier than
> > KProcess, now do you? If that's true for you, you most likely forgot
> > the locking issues. "Works for me" doesn't count anymore when doing
> > MT. You can't really test MT programs. They just fail when the other
> > CPU skips a cycle and that will never be reproducable again :-(
> >
> > I know you know all this, but I wonder why you ignore it?
>
> And I wonder why you don't implement a better solution for the "pipe
> through" case. The "pipe through" filter action was the cause for the
> most annoying blocking operation in KMail. If you present a better
> solution we'll dump the current approach in no time. But until then the
> current solution is 1000 times better than what we had before. Stop
> talking! Start hacking! A patch says more than a thousand words!

Marc, you are certainly a brilliant software architect with really good 
ideas and concepts. Unfortunatly there is one problem left - pure ideas 
don't create software automatically. You have to proof that your ideas are 
right, and you can do that only by writing code yourself or letting others 
implement your ideas.
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. ;-)

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.

Andreas

_______________________________________________
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]