[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Neat thing



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

> > 	* there should be a 'adaptive nnimap-request-list method that
> > 		first does 'fast and only if it's less than, say 20,
> > 		mailboxes, does the 'slow method to fetch mailbox
> > 		information. Listing folders on Cyrus public IMAP
> > 		server is slow. I don't think we should go for the
> > 		'fast method 100 %, in most cases there is only a very
> > 		limited number of mailboxes.
> 
> The best thing would be to send a dummy result to request-list and
> then override the result in update-info. The problem is that when I
> do this, it gets set but never used.  I sent mail off to Lars asking
> about something that would help get around this.  I've spent a long
> time tracing though Gnus and have gotten nowhere on this.  Any
> Ideas?

You mean like the 'fast method?  What's the problem with Gnus storing
that bogus information?  When you do update-info you override it, and
if you don't there isn't much to do but wait until the user runs
update-info or removes the mailbox. It won't hurt anything, would it?

Perhaps I don't get what you mean.

> > 	* Really should split up 1:* header fetches to smaller
> > 		chunks. It would probably take hours to fetch all
> > 		headers in huge groups, and I can't find any way of
> > 		stopping it. (C-g interrupts everything ok, but the
> > 		server is still feeding me the headers).
> 
> That is a toughy.  I'd like to be able to tell the server to stop
> when we interrupt.

I don't think this is possible. You could send a BYE, but I don't
think it will interrupt anything, so you'd still have to wait for the
BYE response tag before you could close&re-open the connection. And
since nnimap doesn't store passwords, you'd have to type it in again.

The IMAP implementation recomendation draft recomends splitting up big
fetches so we should really do this. This also applies to articles, we
should do FETCH RFC822<0.10000>, then RFC822<10001,20000> and so
on. But this is extremely low priority for me.

/S