asynchronous backends

[Greg Stark <gsstark@MIT.EDU>]

Ok, so sometime late in the september Gnus cycle i sent a nice long post
describing how an asynchronous interface could be done. Looking at the code
and the documentation now, it seems only half of what i described was done.

Namely, it's nice and all that nntp can pre-fetch articles before i ask for
them, but that's not the really cool idea. The really cool idea is that when i
enter a new group and there are four gazillion new articles and i really want
to read them all, while Gnus is fetching the NNTP scan it can let me go back
to editing my files (edit files? in emacs?) In general it really sucks a lot
when my emacs freezes up and i can't do anything without aborting the long
Gnus operation, some of us feel, uhm, like less of a person when our emacs is
locked up.

This would also let Gnus do some other cool things, like request group lists
from multiple servers at the same time. This makes more sense if more than one
backend is involed; if i have a slow network, why not go poking around in my
files while you're waiting for the nntp server to answer? Or let me start
reading my mail while it's still fetching the group list from some other
server. 

The reason i posted the original message was because i was implementing a
backend for which the existing emacs interface was asynchronous in precisely
this way. I still feel ashamed that i can't reproduce the single nicest
feature of the existing interface in my Gnus backend.

If you don't believe me that this is possible, think of the Man package. There
are some tricky bits, and if you try a second operation using the same virtual
server it may have to lock up anyways, but it could be done. I'll go find my
original post if needed, it explained this in more detail.

greg