Re: [Evolution-hackers] CamelFolder updates

[Dan Winship <danw helixcode com>]

Hm... the stuff to deal with "very big folders" was added after Jim
Gettys talked to us about Pachyderm. The idea being that if the user
did select some folder/view with lots and lots of messages (say,
10,000), you'd want to only present some limited number of them rather
than the whole thing.

Particularly in the case where the mail is remote, even fetching the
summary of all 10,000 or so messages could take an unfortunately long
time. And you can't make a vFolder until you have the summary.

> The summary will always have to be in-memory for any performance
> at all

Right. The idea was that the user would just be working with a subset
of the folder, and that subset of summary would be in-memory.

> >    We've talked about removing the by_number interfaces, but some
> >    stores have no concept of UID, so if they're forced to implement
> >    "pretend" UIDs, they'll have nothing but message numbers to work
> >    with.
> 
> I see no problem with that, personally.

The point being that then the UID operations are no more thread-safe
than the message number operations were. Although we can do the
"message numbers never change while the folder is open" hack for just
those folder types then. But really then, we're going to want a
"unique ids aren't really unique" flag on CamelFolder.

-- Dan