Re: Gnus v5.2.8 is released

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

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Tue Jun  4 13:46:45 1996  Scott Byer  <byer@mv.us.adobe.com>
[ Lots of cool speedups for nnfolder. ]

On the subject of mail speedups, it'd be nice if nnmail-get-new-mail
didn't loop over all the specified spools for every single group.
This doesn't seem like a speed hit when all you're paying is a stat on
an guaranteed-to-be-empty spool file for all groups after the
first...but it's -huge- when one of those spools is a pop server
accessed over a PPP link.  I'd even consider this a bug. :-)

I thought it'd be a simple tweak to nnmail-get-spool-files, and I
still do.  But I'm not too clear on the interaction with summary-local
settings of nnmail-spool-file (i.e., from the group params).  I also
spent all my time wandering around with my jaw open inside the
aladdin's cave of nnoo.el (very very kewl, Lars).  Should have known
better than to breeze into Lars's code after 5-6 months expecting
things to stay the same.

If someone would clarify/enumerate the ways in which spool files can
be specified and/or modified on a per-group basis, I'll fix this over
the weekend (gonna read CoS till then :-).

[ Unrelated, but I'll throw it in here ]
Maybe we should stare long and hard at the different sources of
messages, and how they differ.  Right now, it's still somewhat random
as to how different backends access new messages--I mean how the user
specifies the source of new messages, nnoo unifies the actual code
nicely.

For instance, most mail backends will get mail from the central
spool.  The central spool is split into every group and should
be accessed just once per get-new-news cycle.  Some groups will have
their own spools (nnmail-use-procmail).

POP is akin to a central spool.

News, OTOH, always has a unique source per group.  

IMAP will use *both* methods.

It'd be nice if there was a way of specifying the characteristics of a
backend, so that nnmail-get-new-mail could be intelligent about how
often and when to access the spools for a given backend, w/o having
that information hardcoded.

It'd also make it easier to make GNUS extensible in the sense of being
able to 
  1) add nnfoo.elc to your load-path 
  2) set a few variables that completely specify it's behaviour 
  3) call a GNUS-provided function to register itself with GNUS.
and have it work just as well as any native backend.

nnoo goes a long way towards this already.

-- 
Sudish