Networking, Sharing and Syncing

Goals

• Multiple types of storage, like sql, caldav, ical, exchange
• Sharing a calendar safely
• ical storage on local files and remote (http) files
• offline support
• Simple UI
• Simplify code

Points to remember

The different storage types will be created using different implementations of the calICalendar interface. So far so good. The network is where the problems come. You don't want a different implementations just because the data file is stored in a different place.

Also, it should be possible to mark a certain calendar for offline use. If marked, calendar should download the events to a local file. Then it needs to sync when coming online again. Thoe code to do this should be shared for all different calendar types.

The code to upload and lock a ics file also should be centralized.

For the best sharing, you should actually do syncing. This is to keep the locking time as short as possible. You want to locally change the event, and then sync the local file to the remote. And at regular intervals, sync the remote to the local. (Or only at regular intervals, not when editing. Could give more conflicts, but better performance).

Idea

The non-ical calendar types do their networking themself. The ical types are wrapped. This wrapper does the networking. It somehow, magicaly, knows if the file is shared etc. It then can do the needed actions. The front-end only deals with the editing of events etc, it doesn't do anything with uploading the calendar and all that. Why the wrapper and not just let the calendar provider handle it? because calICalendar doesn't have a way to set those magic parameters. And it doesn't make sense to add them, because other impl's don't care about them.

For offline, another wrapper. This wrapper makes sure there is a local copy of the data, and this data is synced when going online. All actions the frontend does on the calendar go through the local cache.

For this to work, if a property of a calendar event object is made, the wrapper should be notified that something has in fact changed, and that it can go upload the data. More details on this are needed. (Wrap the events too?)

Alternatives

Create 1 wrapper: syncing. This wrapper handles offline. But also sharing, because as said before, sharing is syncing. Ofcourse, this only works if you can only share and sync ical files. Not a great idea. So forget about it.

Or for syncing, use observers, and add a onBeforeEdit notification. So the observer can store the not-yet-modified event. No need for wrappers. This observer can also be used for publishin changes to a remote location automaticly. In other words, for remote calendars.

Syncing

Moved to Calendar:Syncing Algorithm