From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/12796 Path: main.gmane.org!not-for-mail From: Greg Stark Newsgroups: gmane.emacs.gnus.general Subject: Asynchronous backend interface Date: 07 Nov 1997 02:28:38 -0500 Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035152270 5733 80.91.224.250 (20 Oct 2002 22:17:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 22:17:50 +0000 (UTC) Return-Path: Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by altair.xemacs.org (8.8.8/8.8.8) with ESMTP id AAA01343 for ; Fri, 7 Nov 1997 00:24:36 -0800 Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by xemacs.org (8.8.5/8.8.5) with ESMTP id CAA12454 for ; Fri, 7 Nov 1997 02:25:06 -0600 (CST) Original-Received: from claymore.vcinet.com (claymore.vcinet.com [208.205.12.23]) by ifi.uio.no (8.8.7/8.8.7/ifi0.2) with SMTP id IAA03190 for ; Fri, 7 Nov 1997 08:29:49 +0100 (MET) Original-Received: (qmail 17833 invoked by uid 504); 7 Nov 1997 07:29:48 -0000 Original-Received: (qmail 17830 invoked from network); 7 Nov 1997 07:29:46 -0000 Original-Received: from portC52.Generation.NET (brnstnd@kramden.acf.nyu.edu@205.205.118.208) by claymore.vcinet.com with SMTP; 7 Nov 1997 07:29:45 -0000 Original-Received: by portC52.Generation.NET id m0xTiqM-000AtSC (Debian Smail-3.2 1996-Jul-4 #2); Fri, 7 Nov 1997 02:28:38 -0500 (EST) Original-To: ding@gnus.org Original-Lines: 38 X-Mailer: Gnus v5.4.64/Emacs 19.34 Xref: main.gmane.org gmane.emacs.gnus.general:12796 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:12796 Wouldn't it be wonderful if you could check for new news while editting a buffer. Or Gnus was capable of querying more than one backend at the same time? Or if you could be reading one group while generating a particularly large summary buffer at the same time? All these things really are possible, though some might not be good ideas :) *** They do NOT require a multi-threaded elisp interpreter. *** Honest. Half the job is already done when nntp.el was restructured to support asynchronous prefetches. The problem is currently that the interface between Gnus and its backends is inherently synchronous. It needs to be changed to pass a callback function and a closure datum to the backend functions. Then they could optionally return without the requested data, implicitly promising to call the callback function when it becomes available. I've proven such a feature would be great, the current development of my nndsc backend enters a recursive edit during long operations. The ability to continue to use my Emacs while they go on is incredibly useful. I don't think it would be a good idea to use this approach in multiple backends though. If you don't believe me that this would be possible check the archives for the two previous times i've proposed this, the first would be near the September Gnus code freeze, and the second sometime during Red Gnus development. It wouldn't be useful for everyone all the time. If you have a very fast network connection your emacs might be unresponsive handling i/o. But if you have a handful of slow foreign servers it would be very useful to scan them while also getting all the quick stuff at the same time. If you have a slow network connection it would just be nice to be able to download large summary buffers without locking up your emacs while they download. greg