Re: feature request: caching

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

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

> > 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!

> Would anything break if we return MIN=1 MAX=999999999 ?  I'll read
> some Gnus code...

This is not a bad idea for the 'fast method.  Although, the idea
would be to return "I don't know".  I have been talking to Lars
about returning "0 0" or something like this to indicate it.

> > 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.

> This looks promising. Exactly what does a backend has to do to support
> 'some?

We just have to provide nnimap-request-groups.  I wrote this a long
time ago, but I commented it out since it wasn't "needed" and I had
more important fish to fry.  I'll fix it up.

> > Ideally the request-list would happen, but Gnus would ignore the
> > min/max we send and just look at the group names.

> If Gnus doesn't use min/max for something useful, perhaps we could fix
> Gnus.

I agree.

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

> This is my number two, I think. My number one problem is
> nnimap-request-update-info taking ages (I have 30-40 subscribed IMAP
> groups). nnimap-request-list is really fast compared with this.

I can see how that could be.  My test groups are small.