Confirmed users
503
edits
Calendar:Networking Sharing Syncing: Difference between revisions
Jump to navigation
Jump to search
Calendar:Networking Sharing Syncing (view source)
Revision as of 23:04, 24 January 2005
, 24 January 2005no edit summary
No edit summary |
|||
| Line 5: | Line 5: | ||
== Networking, Sharing and Syncing == | == Networking, Sharing and Syncing == | ||
Goals | ==== Goals ==== | ||
* Multiple types of storage, like sql, caldav, ical, exchange | * Multiple types of storage, like sql, caldav, ical, exchange | ||
| Line 14: | Line 14: | ||
* Simplify code | * Simplify code | ||
==== Points to remember ==== | |||
The different storage types will be created using different implemantations 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. | The code to upload and lock a ics file also should be centralized. | ||
| Line 26: | Line 27: | ||
=== Idea === | === Idea === | ||
The non-ical calendar types do their networking themself | 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 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 | 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. | For offline, another wrapper. This wrapper makes sure there is a local copy of the data, and this data is synced when going online. | ||
| Line 40: | Line 41: | ||
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. | 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. | ||