Asynchronous nntp.el

Asynchronous nntp.el

[Lars Magne Ingebrigtsen]

I have rewritten nntp.el to be totally asynchronous.  Process filters,
callback functions -- a very flexible architecture.  I'm moving the
`nntp-asynchronous-' stuff (that was used for article prefetching) up
into the Gnus code proper, so that all other future backends capable
of being asynchronous don't have to duplicate that code.  (For
instance -- there's no reason why nnml using ftp to read messages
shouldn't be asynchronous.)

When I get the whole thing working properly, writing functions for
postponed commands (and stuff) shouldn't be much work.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Asynchronous nntp.el

[William Perry]

On 19 Jan 1996, Lars Magne Ingebrigtsen wrote:

> I have rewritten nntp.el to be totally asynchronous.  Process filters,
> callback functions -- a very flexible architecture.  I'm moving the
> `nntp-asynchronous-' stuff (that was used for article prefetching) up
> into the Gnus code proper, so that all other future backends capable
> of being asynchronous don't have to duplicate that code.  (For
> instance -- there's no reason why nnml using ftp to read messages
> shouldn't be asynchronous.)
> 
> When I get the whole thing working properly, writing functions for
> postponed commands (and stuff) shouldn't be much work.

  This is great news.  I'm working on rewriting all the URL stuff to be 
asynchronous as well.  One thing you might want to consider doing is 
having all this stuff be in an after-change-hook in the nntp buffer.  
That would save all the strings getting cons'd, but it depends on what 
you are going to do with the data I guess.  But still, one big string is 
better than 15 smaller strings + 1 big string.

-Bill P.