Re: [Evolution-hackers] Camel Data Cache mechanism

[Jeffrey Stedfast <fejj novell com>]

On Mon, 2007-06-11 at 15:27 -0300, Sebastien Tandel wrote:
> Hi,
> 
> 
>    I am looking at the way CAMEL is working and have some questions
> about the cache implementation.
> 
> First, let's see if I've understood the mechanism basics (and, of
> course, don't hesitate to correct me if I'm wrong :))
> 
> Camel has a "generic" cache system which stores objects in Camel Bags.
> This camel data cache uses CamelStreamFs to store the "real" objects we
> want to cache. According to the way it is implemented now :
> - It is not possible to bound the size of a cache. There only exists
> timer for expiration/invalidation data.
> - And each of these CamelStreamFs uses a path build by the IMAP provider
> (in my case). This path is built with session->storage_path and
> camel_service_get_path() but I was unable to determine the value of
> session->storage_path. I made here the hypothesis all the objects are
> stored on the disk ...
> 
> Based on these assumptions, here are the questions :
> 1) To what I've seen, the cache is on a fs ... Is there any project
> which intends to have some cache in the main memory? or is there a
> possibility to use a tmpfs?

not afaik.

> 2) Could we imagine to be able to limit the size of the cache?

I don't see any reason why this couldn't be implemented :)

> 
> I was wondering whether it could be possible to have a mechanism which
> would be like a two-level cache. The first level is the main memory of a
> size X, in which are stored the more recent accessed objects and the
> second level the hard disk with as well a bounded size if possible and
> finally access the network if the information is not cached.
> Is that a crazy idea? Or are there already some mechanisms implemented
> I've not seen?

Is there any reason to do this? What problem would you be solving?

The cache is typically only used for messages from a remote host (in
fact, I can't think of anything else it's used for). The problem with
trying to keep an in-memory cache is that users don't typically keep
hitting the same message, so there seems to be little point in having an
in-memory cache on top of the disk cache.


Jeff