Re: Blue (or was it yellow?) GNUS suggestions

[Sudish Joseph <sudish@ix.netcom.com>]

Lars writes:
> Sudish Joseph <sudish@vnet.ibm.com> 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