Re: Incrementally filling up the view

[Philip Van Hoof <spam pvanhoof be>]

On Wed, 2007-02-14 at 09:55 +0000, Dave Cridland wrote:

> > 
> You can also fetch the summary data in smaller chunks, which allows a 
> faster response time when the user wants to read a message (or 
> whatever).

And guess what, I am fetching the summary data in chunks of 1000 summary
items each. So if I just get my locking more fine grained, I can already
make this work.

And that with good old Camel :-)

Well, I think I finally got the locking to be really correct after I
introduced two extra locks in Camel. It hasn't had any "strange" locks
and sudden crashes anymore since last week, and these weeks I did most
of the IMAP testing. :-)

I'm thinking about adding one socket that is kept in closed most of the
times but that can be used if in the background something is happening
while in foreground the user for example wants to get a message (a
read-only operation and only if the normal connection is used, else that
one will be used). A small 'socket' factory :)

So then it'll usually be one active stream, and sometimes two streams.
One for downloading summary and one for getting messages while slash if
downloading is taking place in the background.

But first incrementally filling up the view. Else ain't that situation
going to happen in tinymail based MUAs (since it waits until the summary
is fully fetched anyhow).

> > I'm expecting all this to start working between now and a month and 
> > demo -ready around FOSDEM.
> > 
> > The good news is that Dave will be at FOSDEM. And I was hoping to 
> > be the smartest IMAPper at FOSDEM this year. Damn :)
> 
> I won't be either - since Alexey Melnikov is also showing up.

Cool :)