During the last week, two major funtionalities were implemented in the program:

1) Import all events from Google calendar (GCal) into the Evolution cal(ECal)
2) Merge all the ECal and GCal events and drop them onto Evolution

In order to get all the GCal events, an HTTP get request was sent to the feed URL, and the response stored in memory (as opposed to files in the previous versions) in a buffer. This buffer contains the GCal events in ICal format. This was converted into a VCALENDAR component and each VEVENT component present, added onto Evolution.

Merging required obtaining the events in both calendars in VCALENDAR format. GCal events were converted into VCALENDAR format using the same algo as described above. In order to obtain the ECal events, a query for all objects was sent to the EDS. This returned a list of (sub)icalcomponents. Now, a top level VCALENDAR componenent was created and each icalcomponent obtained in the query added into the top level component. Once both the calendar's events were obtained as VCALENDAR formats, they were merged into one VCALENDAR component, resolving any problems with conflicting Time Zone IDs. The merged component was then dropped into Evolution.

The last two weeks have been filled with potpourri. As my day job ended, hell ensued, which was coupled with setting down project continuity arrangements. (During that period, I somehow got myself sick too, making matters even more difficult.)

I started working the log_reader plugin, which would transparently read (for viewing) logs created by other instant messaging programs. The scope of this second project is to finalize MSN pre-Live and Trillian reading, and possibly also MSN Live.

I also filed a request to purl.org to create the /ns domain, for use with XML namespaces. Either it got declined or it never went through.

After a couple of weeks of research, trial, error and mailing lists, my program can now open the default Evolution calendar and add/delete an event from it. It was quite annoying that one of the (important) processes I had to implement was done by a libecal library functions that was NOT listed in the API reference docs!! I spent a days trying to do the same thing in different, more complicated ways, when all I needed was this little function.

Moral of the story: Rely solely on .h/.c files for all function listings

Moving on to background and algorithms, a ECal client is where you can "store" events, contacts etc. In order to create/open one, you need an ESource. An ESource holds the settings required for a calendar client which is stored in gconf. The client is associated with the backend through the protocol specified in the uri stored in ESource. Eg: uri starting with file:/// would refer to file backend, webcal:// would be pointing to webcal backend.

This week was one of the most difficult weeks thus far.

I completely rewrote the unified logging specification and then the schema. I had writer's block about 75% of the time. I even recruited a friend to help proofread the spec.

In the end, it was a very fun experience, but I really need to get better at this.

Attached are the specification as of now. Since the schema can't be attached, you'll have to use the link that will bring you to the latest available version. Of course, 0.4-02 is already in the works as this is being written. =)

You know you have been coding too much....
when the knight in your dreams is an Evolution Calendar!

For the past week, I have been reading tons of code and docs, trying to figure out how exactly EDS (Evolution Data Server) works. Right now, what I am left with is a pot pourri of VEVENTS, cal objects, cal components, varargs ctors, iCalendar, eCalendar, vCalendar ouch!

My design plan is to obtain the events in some format, convert it into iCal format and drop it into Evolution. Additions/changes/deletion can be logged using callbacks and this log can be used to sync.

Sounds easy enough (um...yeah), but the EDS library libecal is proving to be a pain to use, simple due to lack of documentation. For the past two days, I have been looking through code that uses EDS and the API ref document. Slowly its beginning to fit together, but the fact that open source code is rarely documented well, never ceases to annoy me. I see that so many amazing works of code are simple unusable due to this reason.

I haven't been keeping tabs about what I've been doing for the last two weeks. Things are slowing down because I'm actually getting quite fatigued for no apparent reason. I blame it from weird the feedback loop that I have. See, people tend to sleep more if they're very tired. Unfortunately, more sleep leads to being even more tired for me, giving me less overall energy to work with.

It's a problem I've tried to remedy previously in many different ways but I haven't had that much luck.

For the week of July 2nd, I cleaned up the code that I had added and changed everything to use GIOChannels.

In this entry I will describe my current progress as well as list some algorithms used.

Presently, my program can get the calendar feed, parse XML feed, add, delete, update and edit calendar events through HTTP. Currently, I'm adding/updating using sample XML files that contain the entry data. In the existing code version, the edit URL for each event to be processed is hardcoded. Also, in order to aid testing of the modules, I have implemented the main() in a menu format.

Immediate Future changes to this module:
- Edit URL will be automatically obtained from file
- Better HTTP authentication methods will be implemented

It was quite a productive week.

I implemented a module, that can request for a Google calendar feed and obtain the response, the headers of which contain another URL with a session ID appended to it. Using this new redirect URL, it sends another (get) request to the Google server to obtain the calendar feed in the body of response. This calendar feed [XML] is then parsed and appropriately stored.

Currently working on a module that can add entries to the calendar. This requires the client to do a POST request with authentication. In response, you obtain an authentication token using which another POST request should be sent with the entry to be added [XML data] as content of the request. The token should be added to the POST request header list.

While logging in today, I noticed that Teresa from Ubuntu/Bazaar has also been adding posts to the Weekly Reports category for almost a month now (and I just didn't notice). I'd like to say hi, and I hope this construct has been helpful in getting your ideas together.

I didn't write a plan for this week earlier because it was pretty much the same from last:

• Continue with the specification.
• Change XML Logger's read/write/create functions to use GLib's IO Channels.

However, the week was spent this way instead:

• Trying to figure out what exactly segfaults my branch when on Windows (I seriously don't have a clue yet).

[ I was out of town for the weekend, plus the fact that some amazing World Cup matches going on ended up with SoC seeing very less of me during the weekend. Anyway, here is what was done during the weekdays. ]

-Discovered the wonder IDE - Anjuta!

I could kick myself for trying to add in compilation flags, and spending hours figuring out the dependency between files. With Anjuta, all you have to do is click a button and lo you have a makefile, you have all the necessary flags and every other possible building tool.

-Currently working on a module that is responsible for communication between Google calendar and Evolution calendar. The XML parser was part of this module. Presently, working on the module that handles HTTP requests. This is being done using GNOME's libgHTTP, which can be used for making HTTP requests to the Google server.