So evolution calendar used to send 5 queries to EDS everytime a date is opened or while switching dates/views. This has been cut down to single query. The query is sent for only the view that is currently shown. The events just remain in the model and as soon as the view is changed, the previous events are destroyed. So if one is in day view, only those events would be in memory.
Initially I thought about storing the events for the dates shown in the date navigator and using it in all other views. But while discussing this with federico during GUADEC, who gave a better suggestion to keep only the events needed by the view in memory, which is better. As we query events from a local server (EDS) it should be fast enough. Also with GSoc work getting in soon, it should be just fast!!
Still more can be done:
Have an interface in ECal to just return the dates which has appointments. This would be useful for all calendar applets (date navigator).
Store just summary of the events in ECalModel as view just needs the summary and information to show the icons. I need to wait for slusny to complete the GSoc work so that I can just get the recurring instances instead of master object to just hold summary of events in evolution.
With ECalComponent and icalcomponent:
ECalComponent is a wrapper to icalcomponent. We use both of them at many places. icalcomponent is structure oriented, while ECalComponent is GObject based. Some things which can be improved here,
Avoid cloning icalcomponent at multiple places. ECalComponent has issues in managing memory while resetting the icalcomponent, so if one wants to use an API in ECalComponent, we just clone the icalcomponent and create a new ECalComponent which is bad. Needs some fixing here..
We had some plans for using ECalComponent in all parts of Evolution/EDS hiding icalcomponent, am not sure whether we can still do it as ECal interface exposes icalcomponent in many places. It would be good to use ECalComponent as its object oriented and so would help us in avoiding copying icalcomponent structure at many places. ECalComponent would need more API’s for manipulating icalcomponent which is a reason why we use both of them.