Re: [Evolution] Wish: Uncached IMAP folders

[Jeffrey Stedfast <fejj novell com>]

On Mon, 2006-04-24 at 17:04 +0200, Jerome Warnier wrote:
> Le lundi 24 avril 2006 à 11:05 -0400, Jeffrey Stedfast a écrit :
> > On Sat, 2006-04-22 at 22:31 +0200, Jerome Warnier wrote:
> > > Le mercredi 19 avril 2006 à 13:52 +0100, Pete Biggs a écrit :
> > > > On Wed, 2006-04-19 at 08:39 -0400, Patrick O'Callaghan wrote:
> [..]
> > > > For me, I would like a way of selectively marking folders for checking
> > > > for new mail - mail only appears in some of my folders (mainly as a
> > > > result of server side filtering), the vast majority either get populated
> > > > as a result of Evo filters, or things get put there manually.  At the
> > > > moment Evo takes ages to sort itself out when I first start it because
> > > > it goes through all my subscribed folders looking for new mail - I don't
> > > > want to untick the 'Check for new messages in all folders' because there
> > > > are some folders that I want to check - I don't want to unsubscribe the
> > > > folders because I use the (unchanging) information in them.
> > > Using the IDLE IMAP extension is probably better, though...
> >
> > I don't think you quite understand how IDLE works (or, rather, /doesn't/
> > work)
> Well, no then. Please tell me...

The problem with the IDLE extension is that it only monitors the 1
folder that is currently in the SELECTED state, which means we'd still
have to poll all of the other folders.

The only thing IDLE gains us is "instant" notification of new messages
in the folder currently opened (in the backend, which may or may not be
the same as the one being viewed in the front-end) IFF (if-and-only-if)
the client is currently idle him/herself in that folder.

What does this mean? It means, if the client is currently chatting back
and forth with the server (user is reading mails, so we are sending
FETCH requests to get those messages or whatever), then we'll get
untagged responses for new messages as they arrive in that
folder /anyway/, without the need to poll that folder.


Now, of course... this assumes that the messages the client is reading
aren't already cached locally, because if so - it won't go to the
network (theoretically, altho I think there are bugs about that - it
might still request the body structure in order to piece the message
parts back together if the message was large enough to be broken into
smaller chunks in the local cache).

Hope that clears things up a bit...

Jeff