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

List:       kmail-devel
Subject:    Re: PATCH: Asynchronous filtering
From:       Marc Mutz <mutz () kde ! org>
Date:       2003-10-27 21:13:51
[Download RAW message or body]

On Monday 27 October 2003 21:26, Ingo Klöcker wrote:
> On Monday 27 October 2003 19:37, Marc Mutz wrote:
<snip>
> The problem being that gpgme is still GPL licensed which would
> prevent a KDE abstraction of gpgme to be included in kdelibs. But we
> had this discussion before.

I don't see a problem. gpgme is so much more advanced than anything we 
could hammer together, and we already use it for OpenPGP/MIME and S/
MIME, that it would be foolish to prevent gpgme use b/c of it's GPL 
status. KDE impairs itself would it reject a kgpgme from inclusion in 
kdelibs.

But I was talking about KMail here. kpgp isn't in kdelibs, either, or is 
it?

<snip>

Ingo, I can't help you if you expressedly avoid to understand my 
arguments :-)

Ok, one last time:

> > You use threads iff
> > 1. The operation is parallelizable or, but not chunkable.
>
> Filtering is perfectly parallelizable.

_and_ chunkable...

> > and
> > 2. The operation takes a relatively long time
>
> You don't seem to be using spamassassin.

I do.

> Piping messages through 
> spamassassin takes an immense amount of time.

But it's not KMail that hogs the CPU, it's spamd and IO.

> > and
> > 3. The operation is mostly CPU-bound, not IO-bound
>
> It seems to be CPU-bound. At least my KMail is absolutely unusable
> while spamassassin scans a message.

Might that be due to the fact that we use the KProcess in blocking mode? 
>:-(

> > and
> > 4. KIO-slaves can't do the work
>
> A KIO-slave for "pipe through"? I don't think so. ;-)

No comment...

> > and
> > 5. The operation doesn't need to communicate much
>
> The "pipe through" filter action doesn't need to communicate at all
> except when it's finished.

Might that be due to the fact that we work with an external process 
already there? What _please_ could possibly be the point of using a 
QThread to pipe stuff to/from a KProcess operated in _blocking_ mode 
when KProcess can be used in _async_ mode, already?

> BTW, 2-5 also apply to OpenPGP operations. 1 also applies in case a
> message (e.g. a digest) consists of multiple signed text blocks/
> messages.

yeah, yeah. Of course if /KMail/ calls gpg in parallel, gpg will 
magically forget it's keyring locking and everything will be fine, 
won't it? But guess what? You can do that with multiple GpgmeCtx's 
_already_. Async. Non-blocking. Non-threaded. And if gpg finally get's 
it's server mode, KMail will automatically use it and be sped up due to 
reduced time spent in the keyring parsing code of gpg. :-o

Marc

-- 
It seems that the only thing worse than being an enemy of the US is
being a close friend and ally.
     -- John Horvath, "The Meaning of Friendship", Telepolis #14395
_______________________________________________
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]