Comment 6 for bug 549647

On Mon, Jun 21, 2010 at 3:37 AM, Rodja <email address hidden> wrote:
> The U1 bug is fixed and I've succsessfully synced all my notes by using
> the newly havy refactored code. The next step will be to implement
> uploading changed Notes to the remote server and hence implement basic
> editing of notes.
>
> Until now I've come up with three questions regarding the Tomboy sync
> code:
>
> 1. Aquiring Lock
> Is a lock aquired by connecting to the remote server and making shure we get a current-sync-guid as it seems to be done in Tomboy (WebSyncServer.cs:62)? How is the unlock done?

There is no actual lock acquisition in web sync. Uploading notes is
done as a single request in which you include the new sync revision
you expect you'll be creating. If somebody else has done a sync by
the time your request hits the server, the server will say "uh oh,
you'd actually be creating rev N+1, not N, so I'm not going to accept
this sync", and there will be an error PUTing the request.

Lock acquisition is only needed in the case where we're faking a
server, like with the fuse-based sync backends.

> 2. Resetting Client
> In SyncManager.cs:425 happens check to make sure the current-sync-guid is the same as the one known by the client. Otherwise the client is resetted. The comment indicates this is needed to make sure local notes are not deleted when the server is wiped/reinitialized. Will the server change it's guid when wiped? Also I wonder why a reset is going to help in such a situation.

A properly implemented websync server would change its per-user guid
if the user decided to wipe his notes and start over at rev 0. If a
user was at rev 5 (for example), then wiped his notes and went back to
0, and sync'd 5 times with Tomboy before ever syncing again with
Tomdroid, and we did not have the per-user guid, Tomdroid would think
the server was in the same state as the last time it sync'd based on
rev alone.

This assumption would be wrong and could easily lead to data loss.

> 3. Title Conflicts
> What is the purpose of the title conflict resolving code (SyncManager.cs:450)? It seems to search for notes which
>  * have changed/created on the server since last update
>  * are not found via UUID on the local side, but
>  * have the same title as a local Note but different content
> If I unserstand correctly, this can only happen when two clients seperately create a note with same title. Must the title be unique within Tomboy? Otherwise I do not understand why this title conflict code is needed at all...

Titles need to be unique in Tomboy.

Hope this helps!