Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the backend's native modify timestamp if available #4

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ralflang
Copy link
Member

@ralflang ralflang commented Mar 9, 2021

Allow the backend to provide own modification timestamps.

The main target is the turba ldap driver, but implementation is driver agnostic. There are two use cases:

  • Data is modified by backend without Horde knowing (i.e. some administrative 3rd party tool)
  • Data is modified by horde but in a different context. You have one addressbook where a user or delegate can see and write to many fields, including information intended for a restricted audience. That same ldap tree is exposed as a separate addressbook with a more limited set of fields for a wider audience. The updates of the user are correctly written to the history api for the original addressbook, but not for the public addressbook.

Both cases result in the same behavior:

  • Data is correctly shown in Horde.
  • Sync mechanisms like CalDAV retrieve the correct recent data on initial/full sync
  • Sync mechanisms will never notify clients about a change of the entry, thus the client may overlook changes on incremental/update syncs

This feature is opt-in, the code change will not modify existing installations without further config.
The administrator has to actively configure a __nativemodified attribute to benefit from backend's info.
If present and not null, the backend's info will be used and the history API will not be queried or updated.

One could get almost the same effect by just mapping a __modified attribute to "modifytimestamp". However, modifytimestamp is in a string format, while turba's lastModification method is documented as returning an integer timestamp.

@mrubinsk
Copy link
Member

I see an issue with the fact that the synchronization related API calls Turba_Api::getChanges(), Turba_Api::getChangesByModSeq(), Turba_Api::listBy() etc... all use the Horde_History system to determine changes. The lastModification value on the Turba_Object itself is not used. While this might work for CalDAV only I can foresee the possibility of some race condition where the state of the data becomes inconsistent.

...and yes, I know how long it's been since this was opened :) Better late than never.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants