Re: feature request: caching

[radford@robby.caltech.edu (Jim Radford)]

> radford@robby.caltech.edu (Jim Radford) writes:

> > > I think 1 would improve the situation the most, it should be
> > > implemented. Consistency of data is of course the problem, it's
> > > probably somewhat tricky to do this correct.

> > What type of data are you thinking of keeping?

> nnimap-request-list stuff.

> Nnimap wouldn't do a UID FETCH 1,* (UID) in every group but instead
> use it's locally stored information until someone selects this
> group. Netscape does this, and I think most clients do this. Checking
> for new articles in every group on startup is very time consuming.

> I'm not sure how you tell Gnus about this change though, anyone?

This already exists in two different forms.  We don't want any more
caching.  If you subscribe to 1000 groups then you expect to have to
open 1000 groups to check for mail, but if your server happens to have
1000 groups and you subscribe to 3 then you don't (ever, I think) want
it to open any of the 997 and check.  We currently do.  This is the
problem.  In `nnimap-request-list' we open all the groups just to get
the max and min article numbers.  Gnus thinks this is easy, and it is
for nntp, but it is not for us.  There are two ways to change this
(and I believe caching is not one of them).  

First you can just not open any of the groups.  This can be done by
setting `nnimap-group-list-speed'.  This however returns incorrect
info to gnus, i.e. the min and max article numbers.  Info which BTW I
think gnus shouldn't need for anything!

Second you can use `gnus-read-active-file'.  With this you can keep
the `nnimap-request-list' from happening on a regular basis.  This is
closer to the correct way.

Ideally the request-list would happen, but Gnus would ignore the
min/max we send and just look at the group names.  That way we could
just do a LIST (which is relatively fast) and not open each group which
is REALLY slow).

This need to be fixed.  This is my number one problem with nnimap.