You know whats neat, when Google changes the way things work internally right in front of your eyes!

When I started working on SoC, and till a couple of weeks back, as part of Calendar authentication (ClientLogin), I had to manually obtain the redirect URL. But now, good ol' GCal automatically does that for you!

Um..does that mean I wasted time on a couple of functions? mehh..its all good.

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.

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.

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.

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.

[ 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.

-Working on library that provides an abstraction for handling GData (Google Data API - which uses an XML over HTTP protocol). It should be able to authenticate user, handle HTTP, parse XML etc. This library will be eventually used to implement a calendar abstraction. These libraries utilize GLib and GObject .

-Implemented an XML Parser using GNOME's libxml2 (a library the aids in XML, HTML parsing and other related functions), for our GData purposes. An example of a GData XML (for a PUT request) looks like this:

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">

I spent most of last week trying to get the big picture rather than concentrating on the logic. Below is a short summary of my Google SoC activities for the last week.

• Under the advice of Ubuntu and my mentor, registered the product with Launchpad and decided on the final specifications [https://launchpad.net/products/e-syncplugins/]. Also, created a wiki for the specs [https://wiki.ubuntu.com/EsyncPlugins].

• Registered product with SourceForge.

• Read through most of the EPlugin User Manual
[http://www.gnome.org/projects/evolution/developer-doc/eplugin/]
EPlugin is a language independent framework of helper utilities, introduced in Evolution 2.2 in order to provide modular extensions to it. The manual is currently incomplete and contains quite a bit of formatting bugs. However, it is a good resource for plugin-beginners.

Google Summer of Code 2006 has hereby forced Teresa Thomas, the eternal blog-hater to start her own blog. Quite an achievement on their part. My only hope now is that as time goes on, I change my mind about the concept of "penning down every single little thought that crosses my head for the world to 'admire' ''.

Let me begin by introducing myself. The name is Teresa and nop, I am not always this bitter. I just completed my second year in Electrical and Computer engineering at the University of Toronto, Canada. This summer, other than SoC, I am researching in Integrated Optics at my uni. For SoC, I am working with Ubuntu and my project involves implementing synchronication plugins for the Evolution Calendar. I plan to start with plugins that will sync it with the BlackBerry and the Google calendar, and if time permits, add more to the list.