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?
2) Could we imagine to be able to limit the size of the cache?

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?



Regards,
Sebastien Tandel
_______________________________________________
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to