Note Synchronization Brainstorming

Bugzilla

  • 321037 - synchronize notes across multiple machines

    • Find/put patches here

Overview

  • Syncing is a very important/requested feature, up there with bulleted lists
  • Sharing notes is out of the scope of this feature
  • Should have two modes of syncing:
    • Enter storage URL, and use webdav/ftp to do really simple async background syncing
    • Using Avahi to do automatic sync between nearby computers
  • These two can share a lot of code by making Tomboy run a very very simple webdav server and then just using Avahi to advertise the address.
  • Some reference code exists:
  • Merge conflicts can be dealt with by keeping the local note, create a new note containing the foreign content and then just appending a link to the top of the local note linking to the foreign note

Design (Last updated 18 May 2007)

  • Use a WebDav server as the master copy of notes

  • To connect, a user simply needs to enter the URL of the WebDav service, a username, and password

  • Synchronization occurs in the background automatically
    • Initially, we'll implement a manual sync (user has to press some sort of button to make it happen)
    • Eventually, allow the user to set how often an automatic sync should occur
  • More details in this IRC Log

  • Will need to deal with credentials (storing, caching, etc). Should we offer gnome-keyring integration for GNOME users?
  • Could design this such that there are many possible backends (ie, sync directly with a Subversion repository). Mono.Addins could help make this extensible.

Problems (and Solutions) (Last updated 23 May 2007)

  • How does a syncing client recognize a deleted note (and not re-add it)?
    • Keep file that records rev number, adds, modifies, deletes (probably don't need rev numbers for individual notes, now)
  • What about generated notes? NotD? New notes with same title? (all of these have different UUIDs)
    • Will have to somehow check note titles in addition ot UUIDs.
  • Emulating atomic commits...can we actually do this? How does svn work over file:/// connections?

  • Is a rename different than other modifications?
    • Probably not from the server point of view, but the client has lots of things to worry about with a rename. Our notes do not live in isolation; renaming one note will affect the content of any notes that link to it. In theory, if one client renames a note, all of that client's linking notes should be updated as a result. In that case, once that client syncs, another client will only have to worry about making sure its new and modified notes link correctly to the renamed note.
    • Note rename conflicts could potentially be a nightmare. Maybe we should sync entirely based on note title?
  • What modifications should be synced?
    • Title, contents, tags, last-modified-date (for recent notes menu), pinned/unpinned, startup-note, size/position
      • Syncing size/position may be a problem across different display resolutions/types.

Workflow (Last updated 23 May 2007)

  • User makes changes
    • Adds, modifies, deletes (modifications are marked in note XML, or in manifest?)
  • User initiates sync
  • Connect to server
    • Involves getting stored credentials, or prompting
  • Update from server
    • Check manifest
      • Local .tomboy/manifest.xml lets client know last synced revision
      • Remote manifest.xml lists revision actions
        • "12345 [A] UUID1, UUID2 [M] UUID3 [D] UUID4"
    • Handle Adds
      • Generated notes (NotD) may need special handling, make sure to check titles
    • Handle Deletes
      • If there are local modifications on deleted notes, prompt user to re-add or delete (or automatically re-add?)
    • Handle Modifications
      • In case of local modification, prompt user to pick between (diff-like display? auto-merge? worried about adding foreign note...because we were assuming that the titles need to match)
  • Send updates to server
    • Lock (locks can expire)
    • Get incremented rev number
    • Handle Adds
      • Upload file marked with rev number
    • Handle Deletes
      • Delete file from server
    • Handle Modifications
      • Update took care of merges/conflicts/etc
    • Upload file marked with rev number
    • Update remote manifest.xml
    • Release lock
    • Update local manifest.xml
  • Display sync status to user (should this dialog be integrated with the update/merge/etc prompts?)
  • Rinse and repeat

Apps/Tomboy/Synchronization/Brainstorming (last edited 2013-08-09 00:14:58 by WilliamJonMcCann)