From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4567 Path: main.gmane.org!not-for-mail From: gsstark@MIT.EDU (Greg Stark) Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: 28 Dec 1995 08:35:12 -0500 Organization: Massachvsetts Institvte of Technology Sender: gsstark@fierce-bad-rabbit.MIT.EDU Message-ID: References: <199512280453.XAA00789@perdiem.cygnus.com> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145297 30101 80.91.224.250 (20 Oct 2002 20:21:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:21:37 +0000 (UTC) Cc: ratinox@ccs.neu.edu, ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from moonbase_v.moonvalley.com (moonbase_v.moonvalley.com [204.212.162.1]) by miranova.com (8.6.11/8.6.9) with ESMTP id FAA08933 for ; Thu, 28 Dec 1995 05:58:33 -0800 Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by moonbase_v.moonvalley.com (8.6.12/8.6.9) with ESMTP id FAA21971 for ; Thu, 28 Dec 1995 05:48:07 -0800 Original-Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 28 Dec 1995 14:35:22 +0100 Original-Received: from FIERCE-BAD-RABBIT.MIT.EDU by MIT.EDU with SMTP id AA27462; Thu, 28 Dec 95 08:35:06 EST Original-Received: by fierce-bad-rabbit.MIT.EDU (5.57/4.7) id AA00344; Thu, 28 Dec 95 08:35:14 -0500 Original-To: "Mark W. Eichin" In-Reply-To: "Mark W. Eichin"'s message of Wed, 27 Dec 1995 23:53:52 -0500 Original-Lines: 54 Xref: main.gmane.org gmane.emacs.gnus.general:4567 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4567 Actually, I was just in the process of writing a back end, and it occurred to me I was taking an essentially asynchronous operation (interacting with a subprocess) and serializing it. This is an enormous lose, an existing interface allows users to start an operation and go work on other things; it does this by putting most of the work in the filter function. The basic design to make Gnus do this would be to split each of the backend interface functions into two steps. Gnus would call a normal looking backend function, but would pass a couple extra arguments. One of the extra arguments would be a function the backend function would call when it finshed its processing. I think it would also be useful to pass a nonce along as well and pass it back to Gnus. I would have said this would be very difficult to get right, but I also would have said that about a lot of existing Gnus features. And in my opinion this is the key feature that would make Gnus a lot more useful. I do a lot of things in my Emacs and it frustrates me when it freezes for more than a few seconds. In fact, I think the least robust part of my backend is going to be the joining of the synchronous backend interface and the asynchronous sub-process. It would be easier to implement robustly if both were asynchronous. greg In case I wasn't clear here's an example of what I mean: (defun nnchoke-retrieve-headers (articles call-back nonce &optional g s f) (start-process foo ...) (set-process-filter foo 'nnchoke-retrieve-headers-do-work) 'in-progress) (defun nnchoke-retrieve-headers-do-work (p s) ... process a lot of data but without blocking Emacs ... (funcall call-back nonce 'nov)) obviously some parts of the api need to be fixed to handle this, The nntp-server-buffer must either be passed down or dynamically bound. The concept of a ``current group'' should probably be given up. things like that, but nothing terribly major. (except that i don't think the above example works because of the scoping of call-back and nonce, hmm) greg