Confirmed users
503
edits
Calendar:Networking Sharing Syncing: Difference between revisions
Calendar:Networking Sharing Syncing (view source)
Revision as of 23:06, 24 January 2005
, 24 January 2005update headings
No edit summary |
(update headings) |
||
| Line 1: | Line 1: | ||
= | = Networking, Sharing and Syncing = | ||
== Goals == | |||
* Multiple types of storage, like sql, caldav, ical, exchange | * Multiple types of storage, like sql, caldav, ical, exchange | ||
| Line 15: | Line 11: | ||
== 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. | 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. | ||
| Line 25: | Line 21: | ||
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). | 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 non-ical calendar types do their networking themself. | ||