!MEMOサービスのバックエンドを考える
!!普通にAPI
- まずはサーバ -> クライアントにデータを転送
-- データ量が多くなりすぎる?
- クライアント内で照合
-- サーバ側のほうがrevisionが大きい場合
-- クライアントのほうがrevisionが大きい場合
-- revisionが同じなのに内容が違うとき（エラー）
- サーバに返却
-- 更新差分を送信

データ総量が大きくなると破綻する・・ まぁ良いちゃあ良いのだが

!!差分更新機構
- 通し番号を記録
-- 通し番号のMAX？
- あるKeyの更新があると通し番号をもらってきてrevisionに付与する
- 更新ログに書き込み

- サーバの更新ログと、クライアントの更新ログをsync
-- 両方が進んでいた場合?
--- 衝突ドキュメントを列挙?
--- 文章毎にrevisionを持っておくことで衝突を最小限に抑える
-- どちらか片方のみが進んでいた場合
--- 一方的に上書き
- 新規作成の取得(一意識別子）
-- IDをUUID的なものにすることでどうにかならないか？
-- どうせiPhoneでAutoIncrementが動かない
-- unixtimestamp+randとかで 

!!I/F
- syncTransaction
-- クライアント側の差分を転送
--- クライアント側最終同期トランザクションから最新までを送信
-- 衝突した場合はとりあえずエラーで返す



!!データ構造
- id
-- プライマリキー
- revision
-- 文書バージョン（1更新トランザクションで1+）
-- syncしたタイミングで1+
- transaction_id
-- 全体通しリビジョン番号
- title
-- タイトル
- text
-- 本体
- uid
-- ユーザID（サーバ側だけ？）
- create_revision
-- 作成リビジョン


!!!例
|No|id|revision|transaction_id|title
|-|A|1|1|test
|-|A|2|2|hoge
|SYNC||||
|-|A|3|3|fuga
|-|A|4|4|foo
|SYNC|||||なにもなければサーバはtransaction_id=2