Effort summary

• Week 1: Spent building Cosmo and digging into the code. Administrative issues have also been taken care of. Thanks Travis !
• Week 2: Familiarized myself with CalDAV and built Caldav4j, fixing it so that it works with the new versions of its dependencies (mostly ical4j has changed a bit). Thanks for the patience Bobby (the back of my head knows you owe it a few slaps)
• Week 3: Installed Darwin Calendar Server (which was a bit problematic under Linux) and wrote a few sample clients using Caldav4j. Also, briefly peeked at GData API.
• Week 4: Went back to Cosmo, tracing the code and trying to figure out how should the remote subscriptions module be designed and where should it be inserted. Spent most week understanding how the atom interface, the services and the DAO work together to process calendar requests. This is also when I had no choice but to read up about the SpringFramework^?.
• Week 5: After having a better understanding of the Cosmo internals, I made a first battle plan. Got some dirt under my nails digging into the very undocumented Abdera, but after a certain number of traces and a few chats with Brian the feed service didn't seem that complicated anymore. I started looking into/coding a RemoteItemProvider which later I had to postpone.
• Week 6: Realized that I have not started in the right place, abandoned the atom interface and started considering RemoteContentService. Service stubs have been created (mostly copied from the StandardContextService). RemoteAccessObject interface (essentially combining the ContentDao and CalendarDao interfaces) has been created and a weak attempt at implementing CaldavRao has been taken. A service design has been put up for review.
• Week 7: Experimented with a few code samples of MultiThreadedHttpConnectionManager and HttpClient trying to see if it would be a better alternative to the connection pool used in Scooby. Cosmo model was studied in greater detail in order to be able to code a translator from iCalendar to Cosmo inside CaldavRAO. It has been decided that RemoteCollectionItems and RemoteNoteItems are needed. The design has been evaluated, it has suffered some modifications: one RAO will not represent only one connection anymore, instead there will be two RAOs (one for GData and one for CalDAV) sharing one ehcache for stateful connections; RemoteCollectionItems should keep references of their RemoteSubscriptions such that the service can identify the right RAO for a certain request. It has also been suggested that the CalDAVCalendarCollection API might not be the right choice for this project, but for now it will be used and once remote CalDav^? subscriptions work, a new custom API could be considered.

Coding intensive schedule:

• ~Next two weeks: Finish coding the CaldavRAO and afferent additions to the feed service.
• The week after: Code the GDataRAO.
• Three weeks after: Hope I have buffered enough for solving bugs.

Current Work

• Remote Calendar Subscriptions

Other Intentions

• Performance considerations for remote subscriptions: There are cases when periodically synchronizing a remote calendar with a local copy is a better alternative to directly accessing the remote calendar, especially in a CalDAV capable environment.
• Cosmo-to-Cosmo subscriptions and topology independence: In a scenario where a company has multiple branches, each of them hosting a local Cosmo server, it is natural that employees subscribe to each other's calendars, regardless of the branch servers that they are hosted on. It is interesting to look at ways for these branch servers to form an overlay in order to avoid topology limitations.

-- AlexandruDragusin - 11 Jun 2007