From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/7388 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Red Gnus v0.1 is released Date: 31 Jul 1996 13:17:33 +0200 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035147707 7056 80.91.224.250 (20 Oct 2002 21:01:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:01:47 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id IAA05842 for ; Wed, 31 Jul 1996 08:32:55 -0700 Original-Received: from hler.ifi.uio.no (hler.ifi.uio.no [129.240.94.23]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 31 Jul 1996 17:04:28 +0200 Original-Received: (from larsi@localhost) by hler.ifi.uio.no ; Wed, 31 Jul 1996 17:04:44 +0200 Original-To: ding@ifi.uio.no In-Reply-To: Sudish Joseph's message of 30 Jul 1996 20:25:59 -0400 Original-Lines: 31 X-Mailer: Red Gnus v0.2/Emacs 19.29 Xref: main.gmane.org gmane.emacs.gnus.general:7388 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:7388 Sudish Joseph writes: > How about defvaring all keymaps to empty keymaps in gnus-start or > someplace equally early and having the actual keymap setup code > checking to see if an entry already exists bwefore adding one? That's a good idea. Fix in Red Gnus v0.2. > But, this can cause problems if you do something that requires > bandwidth in itself (for instance, hitting "g" locks me up solid coz > my PPP link is being used for the async fetch -- the b/w won't even be > shared well coz the SYN's will take a longish time to get through to > establish the new connection). Maybe some kind of scheduler or > limiter for the async stuff? Hmm, maybe just using one connection for > all NNTP I/O would suffice since this would serialize requests > automatically, all that'd be needed is intelligent prioritized > scheduling (with preemption based on priority) of commands over that > one link. Well, that leads to all sorts of different problems. Say that the async fetch has started to fetch a Huge article, and then you decide that you want to read some other article. Since there is no way to terminate a command that has already been sent, this means that you'll have to wait until the async fetch has ended. When using two connections, that just means that your PPP link will have to transfer the two articles at the same time, which is no problem. Somewhat slower, but no problem. -- "Yes. The journey through the human heart would have to wait until some other time."