EDS calendar memory

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.


4 thoughts on “EDS calendar memory

  1. Sounds great, I will watch the wiki for news!

    p.s. I think it dishonest that, by omission from your second sentence, you implied Phillip wanted to look for a replacement EDS, and not improve the existing architecture.

  2. Hans de Graaff

    One big benefit of storing the calendar as an .ics file on disk is that it is instantly available to other apps as well, for reading, in a format this is well understood by all calendaring apps. Storing things in a sqlite database means that an export is always needed.

  3. John, ah I mentioned ross and federico’s names as they had explicitly mentioned that the replacement of any application is not the solution. I think philip was pointing to areas which needs to be improved, so i did not mention his name in the second sentence. It does not mean that philip wants to replace EDS 🙂

  4. Hans, currently we store the local calendars (On this computer) in the form of flat ics file. This is not very efficient since we need to parse through the whole ics file to find the upcoming events which is the most common query made in calendar. There is no need to parse the events which are very old unless the user requests for it. Moreover using a database it is possible to organize the data in a better way in order to retrieve them faster. Export may not be needed always unless if you want to switch to another application which does not use EDS for storing data such as sunbird or korganizer which should happen rarely IMHO 🙂 We already have a plugin which can export the calendar data (save to disk) and also a plugin for publishing the calendar information. On the whole moving to a database seems beneficial.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s