In the past I have had some dreams which came true. I used have some dreams, like walking in some place or speaking to someone and after some days the same situation happens in reality. I would then realize that it is the same place, same time and having the same feeling as it was in dream. Exiting, not sure how it happens. In one of the dreams, I became an eagle and was flying. Ofcourse I know it can never be real. May be, was it my flight journey ?😉 Yesterday night, I wrote a poem in my dreaming looking at a beautiful girl. I was observing her for a lot of time and then started writing it. I don remember any of the words, but I only know they were good and I liked it a lot. It impressed her.. I was wondering whether I was thinking about anything related to it before sleeping. Hmm, but I was just runnning my mono test program and got a break through🙂 Writing mono bindings for mailer providers should be easy. With the same happiness I just slept. The dream was no way related. Well let me see, whether am going to see this dream in reality. If it happens, am lucky🙂
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.
I have been working on C# bindings for the EDS backends during this weekend and in some free time. Once this is complete one can write backends for Ice Core, exchange web services, google calendar, remember the milk etc. in C#. With so many client libraries available and rapidness in developing code using c# it would be fun to write backends for EDS🙂
- A BackendLoaderFactory which would load the mono runtime and register all the methods defined by IBackend.cs interace for a c# backend. It will look for .xml files from the extensions/mono directory and load all the c# backends. So a Loader factory would have a list of porotcols supported.
- c# bindings for libedata-cal using gapi which includes the classes, ECalBackend,ECalBackendSexp and ECalBackendCache. I have put it in evolution-sharp at the moment.
- MonoBackend which acts as a connector between the c# and c backend. This implements all the virtual functions to invoke the corresponding api in c#.
- I have implemented 5 apis at the moment which send/get strings/int values from c#.
gapi2-parser was not able to parse a particular class ECalBackend. It said it could not parse a method “last_client_gone” whereas it was able to parse other files. After trying different things, I had a look in to the gapi2xml.pl and found that it was unable to find the class name. The reason was the struct was typdef in some other common header file rather than e-cal-backend.h🙂 It was nice to sort out the issue.around
Some things which are in progress are,
- Implement the the apis which needs to send/get a list of strings
- Notifications calls from c# to c backend.
- Some documentation and a template .cs file to quickly have all the virtual functions.
One of the queries which I have is,
* Is to good to have the provider bindings in evolution-sharp.dll library itself or put it in a separate one ?
Once I get a complete c# backend working in calendar which is not too far😉, am planning to start writing the bindings for mailer. I already know of one gnome hacker (also the calendar co maintainer) who is very interested in developing Remember the milk backend for EDS using c#🙂 which is encouraging me to get it completed fast. Am currently using google calendar .net library for implementing the first c# backend.
This picture with miguel during GUADEC was so encouraging!! and am going to preserve it for a long time to come🙂 Thanks to kangaroo (who was the person to help me with my first issue in mono loader), ankit (showing the right places for me to look at anytime), jhonny (with evo-sharp) and all others who is helping me🙂 This is first time am writing code in c# and it feels good!!