Re: Getting articles asynchronously.....

[Lars Magne Ingebrigtsen <larsi@ifi.uio.no>]

Felix Lee <flee@teleport.com> writes:

> > That would require a multithreaded Emacs kernel, something that a) does
> > not exist and, b) likely won't exist for quite some time.
> 
> you can do most of the job by running subprocesses.  a caching nntp
> proxy could take care of asynchronous article fetching.  once you have
> that, gnus just needs to add a "maybe-it-would-be-a-good-idea-
> to-prefetch-this" entry point to its backend interface.

Howzabout an "asynchronous cache"?  I mean, you press a magic key on
(say) a group, and then Gnus starts fetching the (unread) articles in
the group asynchronously and puts them all in the cache as they
arrive.  The user would typically do something else than wait for the
cache to fill up -- read mail, or whatver.  (If you have a slow disk,
this will mean that Emacs would become more sluggish since most of the
time would be spent in `write-region' calls in the "asynchronous" part
of the code, which would basically be filters that sniffs the output
from the tcp process.)

Then, uhm, when you enter the group all the articles are read from
disk, as usual when using the cache.

... perhaps one could have "postponed commands"?  Process-mark a few
articles, press a magic "postpone" key and then `X U', and Gnus would
do the asynchronous cache thing on the process-marked articles, and
the execute the `X U' when all the articles have arrived in the cache.

Or whatever.

I don't think this would be extremely much work, actually.  It would
be pretty localized and would rely on the already established cache
mechanisms. 

-- 
   Lars Magne Ingebrigtsen * larsi@ifi.uio.no
      (a red leaf that falls from the purple tree)