OUTDATED

Graham Cobb:

I have attempted to expand on my opensync ticket (#208) to suggest some requirements for a possible kdepim plugin enhancement to provide selective synchronisation. The aim of this note is to avoid any implementation suggestions but to describe the desired effect with some examples. The idea is to implement these features as part of kdepim, although they could, alternatively, be part of the opensync core (with the plugin just providing the defintion of the tags for its particular device).

The starting point is that kdepim contains entries which are different in ways that are meaningful to the user. For example, the user may divide their contacts up into irc contacts, friends and family, work, important business contacts and scanned business cards. Another person might divide their calendar into family appointments, business appointments, football matches and stamp collecting club meetings. The mechanisms used to tag them within kdepim are beyond the scope of this note but may include using separate resources, using categories or something as simple as the first letter of the subject (it may also be different for different kdepim components). To avoid suggesting the mechanism, I will call the markers tags.

Requirement 1: It should be possible to limit a single synchronisation to a set of tags. In some way, when configuring the kdepim plugin within an opensync group, it should be possible to specify the tags which will be included. When the synchronisation happens, entries without one of the correct tags are invisible.

Note that it is not enough just to provide the ability to limit the synchronisation to a single tag as multiple tags may be required to synchronise to a single device.

Example 1: I should be able to synchronise just my "friends and family" contacts and my "work" contacts to my mobile phone. I cannot do this as two separate synchronisations because if I first synchronise "friends and family" and then try to synchronise "work" all the F&F contacts on my phone will get synchronised back with the work tag.

This leads to the second requirement:

Requirement 2: It should be possible to specify a tag to be assigned to new entries which are added during a synchronisation. This tag should be required to be one of the tags included in the synchronisation.

Example 2: I create a new tag "phone contacts" to be used for new items synchronised from my phone to kdepim. I must include that in the phone synchronisation (or it is automatically included).

R1 and R2 provide a powerful capability which can handle more than just simple phone synchronisation.

Example 3: Someone creates an opensync plug-in for two-way synchronisation with Microsoft Exchange. This allows me to synchronise my work contacts with an Exchange-based contact folder (possibly a shared folder with my colleagues). I can also synchronise my friends and family contacts with Exchange so I have easy access to them when at work. However, I do not synchronise my IRC contacts because I never use IRC from work.

Unfortunately, the real-world is rarely so easy. For example, a one-way synchronisation from Exchange is available (see  http://www.cobb.uk.net/OWA/owasync.html) which can get data from Exchange but not send updates to Exchange. For this and other reasons (maybe the data is "owned" by some external party), a third requirement would be very useful:

Requirement 3: One or more tags in a synchronisation should be able to be marked as "read-only". These entries are included when sending to external devices but any updates to the entries are rejected.

Some devices may not preserve all data about an entry or it may be very easy to accidentally delete an entry from an external device. This gives rise to another requirement:

Requirement 4: The read-only feature should relate to a particular opensync group, not to the underlying kdepim objects. In particular, it should be possible to synchronise a tag read-write with some devices and read-only with others.

It would be possible to extend the read-only feature to an add-only feature: new entries can be added but existing entries cannot be modified. It is not clear if this feature is actually useful so it is not included as a requirement here, although it could be a possible future extension.

In SelectiveSyncTestCases?, I will attempt to define some test cases (still without assuming a particular implementation!).

By the way, I am aware of the FilteringDiscussion? but my purpose here is to try to settle on what we are trying to achieve rather than how it is achieved.