[Users] Downloads for offline use need to be multi-threaded for speed

Rajib Bandopadhyay bkpsusmitaa at gmail.com
Sun Sep 7 18:51:55 CEST 2014

On 07/09/2014, Ricardo Mones
<ricardo at mones.org> wrote:
>> ... Perhaps
>> it will take no more than a few extra
>> lines of code.
> Priceless! Best joke on this list in
> years!
> Thanks for the amusing moment :-)

Please, Sir! Your email is being
perceived to hurt my feelings and insult
me for my trust upon you. When I wrote
the lines I was _not_ considering my
abilities, but my belief and confidence
about _your_ abilities.

What I tried to convey was that there
already are code-snippets lying there
to be utilised. I meant that you needed
a few original lines of codes and
editing to sew everything together

The same reply goes for Steve, whose
message is posted below.

On 07/09/2014, Steve Litt
<slitt at troubleshooters.com> wrote:

> You should probably download and look
> at the code before thinking there
> would be any possibility of
> multithreading might be a few extra
> lines of code.
> I once tried to add code to turn the
> regular (not the extended) search
> into a recursive search. That sounds
> simple, doesn't it? It wasn't. I gave
> up after three hours of trying to
> figure out which code to put in a
> recursive loop.

Dear Sir,
I probably have more faith on you than
you have on yourself. I have covered my
reply to your post in my reply to Mr.
Mones's email.

On 07/09/2014, Gene Heskett
<gheskett at wdtv.com> wrote:


> That would probably, in the long
> view, be a mistake.  I am still doing
> everything by pop3 here, and while
> kmail CAN do that easily enough, its
> a job its ill suited for because its
> single threaded.
> So I have, for nearly a decade now,
> offloaded that mail fetching duty to
> fetchmail, which hands it off to
> procmail for filtering and delivery
> into a /var/spool/mail/name mailfile.
> And I have a session of inotifywait
> that dies, reporting which of these
> name files has been updated, and when
> it dies, it then sends kmail over the
> dbus, a go fetch the mail command,
> and the parent script then restarts
> it to wait for the next mail arrival,
> and kmail is only configured to fetch
> the mail from /var/spool/mail, and
> that it can do it 10 milliseconds.
> All the other mail fetching activity
> is a background task this multicore
> machine handles with no visible or
> feelable side effects.


Sir, I believe, then making claws-mail
multi-threaded would solve all the
issues about fetchmail, procmail and a
native pop3 email client running with
scripts alongside it!

And I am sure people who have designed
and built Claws-mail have the ability
to have this ability built into it.
From what I have observed, I see that
claws-mail is only a micron away from
achieving that milestone.

Tell me, Sir, which other email-client
that you have come across, has a
pre-processing option available to it?

I hope I have been able to convey my
intent in this message, and apologise
for any inadvertent hurt caused by my
earlier email. It was not at all my
intent to hurt you, but to expect
eagerly that Claws-mail fulfils its
promise as the_ email-client of choice
in future, and also that you fulfil the
promise you have shown in bringing
Claws to where it is now.

My best wishes and regards,
Rajib Bandopadhyay

More information about the Users mailing list