From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6407 Path: main.gmane.org!not-for-mail From: Sudish Joseph Newsgroups: gmane.emacs.gnus.general Subject: Re: Blue (or was it yellow?) GNUS suggestions Date: Mon, 27 May 1996 20:45:21 -0400 Message-ID: <199605280045.UAA00274@atreides> References: <199605252131.RAA00636@atreides> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146867 3498 80.91.224.250 (20 Oct 2002 20:47:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:47:47 +0000 (UTC) Cc: ding@ifi.uio.no 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 SAA04431 for ; Mon, 27 May 1996 18:06:43 -0700 Original-Received: from atreides (sj@atl-ga6-09.ix.netcom.com [199.35.199.201]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Tue, 28 May 1996 02:42:20 +0200 Original-Received: (from sj@localhost) by atreides (8.7.5/8.6.9) id UAA00274; Mon, 27 May 1996 20:45:21 -0400 Original-To: Lars Magne Ingebrigtsen In-Reply-To: X-Mailer: VM 5.95 (beta), GNU Emacs 19.30.2 Xref: main.gmane.org gmane.emacs.gnus.general:6407 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6407 Lars writes: > Sudish Joseph writes: >> * Caching the list of newsgroups locally. >> Updating this cache when we see new groups (gnus-check-new-newsgroups >> is 'ask-server, of course) would keep things very neat. > > Well -- whenever new groups arrive, the cache would have to be > updated. Which would be just as slow as things are now, more or > less. (Most days at least a couple of groups arrive.) Ugh, good point. How about letting the user decide when to update the cached file? We could store the date of the last update in the cache itself, maintaining this date separately from the date used for the current NEWGROUPS stuff? I.e., view the cache as a generic local copy of the active file, to be used whenever we need to know the names of all newsgroups--no need to tie it in with killed groups/new groups/etc. > The thread generation could be put in a daemonic process that would > output one thread at a time and let the user read while it's While this would be very cool in itself, I was thinking more in terms of rewriting the core thread/summary code as a loop that checks the buffer associated with the NNTP connection, sees if any new headers have arrived, slurps all new headers in a list, generates/updates current threads/summary info for that list, then loops back to check the nntp buffer, etc. (It's been months since I did any process interaction elisp, but isn't the actual update of a process/connection buffer already fully asynchronous in emacs?) Anyways, having a separate process actually generate thread info would be very cool, too. I looked into having mthreads (comes with trn, or used to) generate lisp output (even text would be nice, instead of it's current binary madness) about 14 - 16 months back--it's not hard to do, the code is well commented. I had it outputting summaries on threads very quickly. It would need to be rewritten to be demand-driven rather than run as a daemon (I think that was how it was coded, but it's been a long while.) Also, if we're going to go down this path, it'd be nice if we were in synch with the TRN group on the format of the actual thread data passed to emacs. I recall Wayne Davison calling for people interested in threshing out a thread info format appropriate for NNTP servers some time back (a year, maybe). I don't know if anything ever came out of it, but you might want to check... A standardised thread data format, along with a UA-independent daemon that generated this data would be way cool. I'd assume that the TRN people (and any other UA authors, but it's mainly *IX based readers that will benefit from a user-space daemon; other systems might have to wait for servers to support) would be happy to work out a neutral format For e.g., having fields embedded in strings, with "[" and "]" around them would make it easy for gnus to use the lisp reader to parse this data, and should please the parentheses-haters, too. At the very least, it'll have to be text-based (mthreads currently outputs raw structs, so that TRN can read it in even faster--or it did, last I looked). Thinking about it some more, the daemon approach has other good things going for it. For instance, the mere existence of a thread database format wouldn't help lots of people as they would still have to wait for INN to be upgraded and wait even longer for lazy sysadmins to update their local servers. Using daemons would solve this, and help such a format gain popularity quickly. > generating. (Hey -- it could even generate the next group while > you're reading the current one. :-) Coolness. -Sudish