Re: asynchronous backends

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Greg Stark <gsstark@mit.edu> writes:

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

Making Gnus asynchronous in many interesting ways is certainly
possible, but it's just hard.  Even doing trivial stuff (like the new
archie mode I slapped together yesterday (uhm, I think I may be
itching to start writing new code :-)
(<URL:http://www.ifi.uio.no/~larsi/other/archie.el>), and it's going
to be included with Emacs 19.35, it seems (and I have to do some test
runs under XEmacs as well))) takes quite a bit of typing, fiddling,
and means spending *much* more time programming than if one does
things synchronously.

And doing similar things with a behemoth like Gnus is a logistical
nightmare.

The results can be pretty neat, though.  Archie is fully asynchronous;
one just types `M-x archie RET search-string RET' and control returns
immediately.  Using `after-change-functions', Archie logs in on the
server, sends parameters, does the search and parses/generates the
result buffer asynchronously.  (Emacs locks up during the final phase,
though, just like Man does.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen