Re: [Evolution-hackers] CamelFolder updates

[NotZed <notzed 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.

*shrug*

I just dont see it as being practical to implement in the near term.

Perhaps the folder itself (or its path) could represent a subset of
a real remote folder?

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

In the case of an intelligent remote interface (imap?), the vfolder will
partially consist of the result of a remote query not a locally performed
one (so it doesn't need a summary).  Almost everything in the summary
and searching classes (infact, in MOST of camel's classes) will have
to be overriden for the imap provider to work 'well'.

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

Having the folder present a subset of information seems a cleaner
way to do this?

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

There are often other ways of identifing messages
other than their index in an array (address of summary?  checksum
of headers?).

I've said all along something as broken as pop should just movemail
to an mbox (which is basically exactly what evolution mail has to do
anyway, because otherwise it can't apply filters very easily).