Thursday, May 26, 2011

First Step : Getting event information

About Events in Calendar

Events in calendar inherit from the calIItemBase interface and in order to store them in a cached file i wud need to set up some sort of parsing from an event object to a serializable string which I can then write to a file.

As luck would have it there is an icalString attribute in calItemBase which allows you to get the event string in ical Format. I can store this guy and use it to construct a calItemBase object which I can then write to the cloud when online.

Here are the preliminary results.

Wednesday, May 25, 2011

The Great Plan

The Plan currently looks like this

So yeah this is the plan so far, Fallen and Ludovic have asked me to try and extend calCachedCalendar.js if possible because it would allow the providers to use the sync() functions for free without having to implement their own versions. 

So this is how I am going to approach the problem
  • Add a property in IChangeLog interface, which also for offline sync and also stores a ChangeLog file, the implementation would be provided by different providers, and it is to be seen if I can move this inside calCachedCalendar.js but it won't make sense.
  • Modify isCalendarWritable to see if the calendar can be synced offline which basically queries for IChangeLog and gets the offline sync property
  • Add implementation for storing the sync actions in a flat file, for the CalDAV provider
  • and implement a replayChangesOn -> generalized version to handle the two way sync
This week I will try to get the above set up done for at least the delete item method, coz its the easiest so far.

After that the second part would deal with the sync mechanisms and making it truly smart and worth having in the mozilla lightning trunk :-)

I guess I can say that I am quite confident of my understanding of the code in calUtils and calCachedCalendar


Saturday, May 21, 2011

Building Thunderbird + Calendar

Today I spent my entire time working with the building thunderbird and calendar together. I think I cleaned it about 3 times before I decided to backup my changes and update the directory from the start, that means, full clean-up. Everything deleted.

One of the important things I think is to keep updating the code on a daily basis so that you do not fall too behind the working set because it is for all these changes that the local code base falls behind and causes merging troubles.

I still not quite get the version systems CVS, HG, GIT, and others used by people, because it facilitates integration of code faster but it comes with its own set of headaches. Essentially, some body works on some part of the code at a single time, but I guess the versioning systems have their own advantages, especially git.

Long Night ahead, :-)


Wednesday, May 18, 2011

Hacking around the code

First sucess is always a sweet one. No matter after how long it comes.

I spent this week, trying to hack around the calendar code-base.

Instead of making changes to the actual code and then building the product again and again, I am instead editing the application extension directly, since lightning is in the form of an extension to thunderbird, this makes it easy to edit the extension code and test out the functionality real time without the need for a build. This however, means, the application restarts everytime.

Anyways off to making at least deletion part of the syncing process.


Sunday, May 15, 2011

Mozilla Bug Assigned

Finally, I am down with the real stuff to be done. I have been assigned the bug in Bugzilla making me responsible for fixing up of the offline enhancement feature. It also puts a lot of community checks and balances since a number of people have an interest in the bug and would be making sure the fixes i propose are of a high standard.

Look up the details of the bug here:

Wednesday, May 4, 2011

Internet Protocols

Since starting off my GSoC assignment to get offline mode to work on the Lightning extension, there are a couple of things, that are needed to be studied in more careful details. One of them is the protocols that calendar providers use, in order to update calendars.
WebDAV is the base protocol over which a large number of other protocols such as CalDAV and CardDAV are based. HTTP itself does not collaboration among the authors of a document, it also does not say that it is impossible to do so.
As such a working group of the IETF drafted the WebDAV specs and they are being widely in the world right now in creation of newer methods of communication. It is being proposed that WebDAV become the standard of shared documents/resources on the web, thereby replacing FTP and other resource access protocols.
I was going through the specifications this week and found that WebDAV collaborators did not have any WebDAV enabled applications at that time, as such most of their work was based in using e-mails as a form of communicating changes in the document to a central author who then changed the document and mailed the document to the rest. Imagine, how painful it would be to mail everytime, and if the central author is not merging the changes (maybe he takes a break), the mechanism would certainly fail, causing trouble for many.
WebDAV Distributed Authoring Protocol defines a set of extensions to the base Hypertext Transfer Protocol for the capabilities like overwrite prevention, namespace management and properties.
I describe some details below:

  • under overwrite prevention, WebDAV uses shared and exclusive locking mechanism, in order to prevent conflicts
  • by properties, WebDAV protocol allows metadata to be stored and retrieved.
  • namespace management, allows copying, moving and listing of shared resources, also known as collections.
Phew! that was simple. My next target is looking up at the specs of CalDAV and look up its implementation inside Lightning =)