I just read the blogs from ross, philip and Federico regarding the areas of memory usage in EDS. I completely agree with ross and federico that we should fix the existing code rather that trying to look for a replacement. I too once wanted to write a new libical a while ago using glib, when michael advised me and got me into the right path to fix the memory issues in libical rather writing another one. Federico’s fosdem 2007 talk about the profiling desktop applications also provided motivation for this. I think what philip is pointing is about the live query cache which is maintained for every client in EDS (EDataCal). The other issues as federico pointed were about the current sequential query of cache and the handling of recurring events. As federico also pointed out, the human readable content in a calendar view are summary, start/end times, category/alarm/meeting/recurrence icons etc. But there is no need to pass the other contents such as description, the alarm information, sequence etc. to the clients such as a clock applet or a day/month/week view in calendar. EDS currently does not provide the interface for getting just the summary info. We are looking at fixing all these issues for evolution-data-server-2.24. Myself and gicmo had discussions about most of the above issues. We are planning to use sqlite database for storing the events and indexing based on time ranges. I was planning to put the design of the new cache in go-evolution.org to get views from everyone, its getting postponed due to some other work. I will try to put it in the wiki soon with some prototype code done for the same.