SyncML 仕様は役立つかもしれませんが、非常に読みにくく、明らかに SyncML に偏っています。
これをタスク コーチに実装する必要があったため、いくつかのアイデアを次に示します。
変更フラグで十分です。タイムスタンプは実際にはそれほど多くの情報を提供しません。通常、オブジェクトは次のいずれかの状態にあります。
オブジェクトが変更されると、次の遷移が発生します。
- なし -> 修正済み
- 新規 -> 新規
- 削除済み -> (起こらないはずです)
- 修正済み -> 修正済み
および削除された場合の次のもの:
- なし -> 削除済み
- 新規 -> 実際に削除されました (ストレージから削除される可能性があります)
- 削除済み -> (起こらないはずです)
- 変更 -> 削除
同期するとき、デバイスはまず、ステータスが [なし] 以外のすべてのオブジェクトをデスクトップに送信します。これらのいずれかのステータスが != None である場合、デスクトップはユーザーに競合を解決するように求めます。いずれの場合も、オブジェクトはデバイス上で状態なしになるか、状態が削除済みの場合はストレージから削除されます。
次に、デスクトップは独自の変更をデバイスに送信します。デバイス上ですべてのオブジェクトの状態が None であるため、競合の可能性はありません。デスクトップ上のオブジェクトは None 状態になるか、ストレージからも削除され、同期は終了します。
デバイス/デスクトップの状態に応じて、2 種類の競合が発生する可能性があります。
- 変更/削除。ユーザーがデバイスを信頼することを選択した場合、デスクトップ オブジェクトはデバイスのものに置き換えられます。それ以外の場合、デスクトップは何もせず、削除された状態を維持するため、オブジェクトはフェーズ 2 でデバイスから削除されます。
- 削除/変更: デバイスが勝った場合、オブジェクトは実際にデスクトップから削除されます。それ以外の場合、オブジェクトはデスクトップ上で New 状態になり、フェーズ 2 でデバイス上に復元されます。
- 削除/削除: 当たり前。ストレージから取り出すだけです。
- modified/modified: ユーザーは、保持する値をフィールドごとに決定します。これらの選択がフェーズ 2 でデバイスに反映されるように、状態はデスクトップで Modified のままになります。
Modified 状態が各フィールドに保持されている場合、一部の競合は回避される可能性があります。たとえば、デバイスで変更されたサブジェクトとデスクトップで変更された概要を持つオブジェクトが競合をトリガーしないようにするためです。
例として、Task Coach のコードを見てください (SourceForge の SVN リポジトリには、Python のデスクトップ アプリと iPhone アプリの両方があります)。実際には、この場合、より単純なアプローチを使用することにしました。デスクトップの状態を追跡しません。フェーズ 1 (デバイスからデスクトップへ) の後、デバイス上のオブジェクトをデスクトップ上のオブジェクトに完全に置き換えるだけです。したがって、競合はありません (常にデバイスが優先されます)。
明らかに、これは 2 つの固定デバイス間でのみ機能します。複数の電話/デスクトップ アプリと同期する場合は、それぞれに一意の ID を割り当て、デバイス/アプリごとに異なる状態を維持する必要があります。これは毛むくじゃらになり始めるかもしれません。
HTH