Thursday, March 16, 2006

Personal Synchronizable Wiki

A wiki that is locally installed and used as an idea collector.

Features:
  • Team support (share ideas like a real wiki)
  • Merge functionality?
  • Local folders that won't be sychronized
  • Synchronization on-the-fly
  • Client needed
  • Kinda gnutella idea, find each other, distribute knowledge!
This piece comes from http://wiki.mozilla.org/Mozilla2:Unified_Storage

Any plan to have multiuser access (even coarse-grained with full file locks during writes) coupled with offline (i.e. a syncing algorithm, possibly sql based) capabilities? Calendars, addresscards etc. would benefit from it. Typical use: network with a shared contacts storage, which can be accessed directly (rw), or dumped locally for offline use and subsequent sync operation. One way to do syncing might be to store a sequential number (not a timestamp, which depends on the clock, actually the clocks, plural...) for each record/group of records (i.e. a vcard). Every time the record/group is modified, the next sequential number is used. Knowing the max value of this field at the time you go offline, it should be possible to sync the contents of two tables. I am thinking only of a single function to addresses simple situations (which are also quite common), leaving more complex conflict resolution issues to the clients. Assuming identical table structures with an Index field, something like:

sync(recordsetA, recordsetB, indexField, conflictResolution)

conflictResolution = priority_to_A / priority_to_B / duplicate / only_return_a_list_of_conflicts

So defining two items: A and B, and I(A), I(B) their respective sequential indeces, and I(O) the max value of the sequential index of tableA at the time of the last connection, the two recordsets are merged according to the following rules:

  • I(A) <= I(O) &&amp; I(B)<= I(O) : nothing to do
  • I(A) > I(O) && I(B) <= I(O) : A->B
  • I(A) > I(O) && B missing : A->B
  • A missing &&amp; I(B) <= I(O) : delete B
  • I(A) > I(O) && I(B) > I(O) : conflict -> resolve according to conflictResolution

Same thing inverting letters. More complex conflict resolution schemes can and should be implemented by the clients. Syncing two apps based on Uinifed Storage should not be a problem. Syncing with an external application (which does not use the sequential index) is still possible, but it will require an intermediate step (client-side). In this case, a copy of the recordset as of the time of the last connection must be stored. On the next connection, by comparing the old recordset to the new data, it is possible to establish which items were edited offline (i.e. I(B) > I(O))...

Having such syncing functionality within Unified Storage might avoid a lot of code duplication since it is a common task. Moreover it would be more elegant, safer and faster to assign the sequential index internally rather than letting the clients do so.

No comments:

Post a Comment