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

[blind Pete]

On Sun, 7 Sep 2014 10:59:25 -0400
Gene Heskett <gheskett at wdtv.com> wrote:

> On Sunday 07 September 2014 09:32:18 blind Pete did opine
> And Gene did reply:
> > On Sat, 6 Sep 2014 20:41:35 +0530
> > 
> > Rajib Bandopadhyay <bkpsusmitaa at gmail.com> wrote:
> > > Dear Friends,
> > > 
> > > The pre-processing filters make
> > > claws-mail terribly slow to download
> > > posts from newsgroups.
> > > 
> > > The speed could be sufficiently improved
> > > if the downloads are made
> > > multi-threaded.
> > > 
> > > Is it possible to improve upon the
> > > download speed?
> > > 
> > > Could this be implemented please?
> > > 
> > > Regards
> > > Rajib Bandopadhyay
> > 
> > Consider installing a news spool.  I use leafnode, but there are
> > others.  The news spooler periodically downloads news posts in
> > the background, then your news reader only has to fetch items
> > from the hard drive.
> > 
> > One day I have to get around to configuring dovecot to do the
> > same job for mail.
> 
> 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.

Kmail?

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

Books have been written about configuring mail servers.  I find the 
subject a bit daunting.  It would be embarrassing to find that my 
computer was running an open mail relay.  So do it properly or don't 
do it at all, is my position.  

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

You look like you know what you are doing, but I have not come to 
terms with rather a lot of details.  

Why don't you like dovecot?  

> So regardless of your favorite email agent, off loading the online
> mail fetching activities to something designed to be a background
> task will be a genuine enhancement to your enjoyment because you'll
> never have to wait 30+ seconds for it to process and deliver your
> incoming mail in the middle of typing an answer to a previously
> received email.
> 
> Cheers, Gene Heskett

There are long undesirable pauses during network activity.  

-- 
testing
bP
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20140908/688a2414/attachment.sig>