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

["Sudish Joseph" <sudish@VNET.IBM.COM>]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Sudish Joseph <sudish@ix.netcom.com> writes:
> > 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.
>
> That sounds very complicated.  And is it useful?  How many new
> articles typically arrive for the group you're reading while you're
> reading the group?

No, I was rambling about doing this for _every single_ header.  Well,
clumps of headers, where clump is defined as all headers in the *nntp*
buffer at the time you get to the end of the the buffer.

On a fast link, you'd get the same behaviour as today, since more
headers would arrive in the time GNUS finished inspecting the ones
that were there.

On a slow link, GNUS could get a hell of a lot done in the time it sat
waiting for _all_ the headers to arrive.

But yeah, it'd be very complex.  Just figuring out how to let the
user select an article in the midst of the above loop would be pain
enough for anyone.

> I don't quite see how Gnus would be helped by this.  The way Gnus
> threads things is highly user-customizable (gathering, fuzzy subject
> comparison, sparse nodes, ancient articles, ad nauseam).  If we had a
> separate process spewing out the threads at us, then we'd lose that
> Lispish extensibility.

Well, that's why the format of the thread info becomes important.  It
should be general enough to support all that and more :-) Um, fuzzy
subjects are a sorting issue, imho.  If INN was maintaining this info,
one can imagine stuff like "gimme the roots of all threads rooted in
articles that arrived after article n", etc.

> Anyways, the threading itself is no problem.  The most time spent is
> used to generate the summary buffer, and there no external process can
> help us.

Ugh, clarity was never my strong suite.  Here's another attempt.

Currently all events that occur the summary generation process have to
wait upon the arrival of _all requested headers_.  IMO, it'd be a big
win if GNUS went ahead and prepared the summary for the headers it
already has, thus distributing the cost of summary generation over the
time wasted waiting for all headers.  Obviously, this is not a big win
if you're sitting on a fast, unsaturated network--there's a saturated
token ring here at work where it'd help, though :)--but it won't be a
loss either.

It would also improve the responsiveness of GNUS for all users, since
you'd be dropped into a summary buffer almost as soon as you selected
the group.  To get this for people on a fast network, we'd have to add
some crock like always grabbing the first n headers (n being small)
and generating a summary using those before going back to what I
outline above.

This would be a _huge_ win for people on dialup links, and mostly
irrelevant for people with a network card (well, the improvement in
responsiveness would help them, too).

But, like you said, it'd be a pain to code/maintain.


-Sudish