つまり、iCloud はまだ NDA の下にあるが、私の質問は iCloud についてというよりも、iCloud に触発されたものをどのように実装するかということだ。
iCloud がドキュメントを同期するためのサーバーベースのメカニズムであることは誰もが知っています。私はそのドキュメントの側面に本当に刺激を受けています。ドキュメントの同期に集中するのは、私には別のパラダイムのように思えます。私が書いた Web API (それほど多くはありません) はすべて、SQL データベース駆動型でした。
例: 単純なブログ投稿は通常、次のようなものです: タイトル、コンテンツ、公開日、著者を含むデータベース内の行。たとえば、タイトルを更新する場合は、DB のその行/列を更新します。オフラインで変更を行っている多数のクライアントを同期するまでは簡単です。
しかし、ブログ投稿が 1 つのドキュメントである場合、それ自体は、タイトル、コンテンツなどすべてが 1 つのファイル内にある独自の内部構造を維持していました。タイトルを変更すると、ドキュメントがローカルで更新され、ドキュメント全体 (または差分) がサーバーにプッシュされます。サーバーは古いドキュメントを新しいドキュメントに置き換えるだけで、タイトルがサーバー上で更新されます。明らかに、これはマージの競合につながる可能性がありますが、それらは競合するドキュメントをクライアントに送信することで処理できます。
とにかく、私はそのアプローチが好きで、多くの Web アプリ、特にオフライン中にデータを変更し、インターネット接続が利用可能になったら簡単に同期することをサポートしたい Web アプリにとって非常に役立つことがわかります。これは iOS にとっては素晴らしいことです.
私の質問: 私が話していることの名前はありますか? また、そのような技術を実装する方法を学ぶのに役立つ読み物はありますか?
言い換えれば (編集)
iCloud API (現在 NDA の下) は単純に優れているので、REST API を介して同期する単純なコア データ オブジェクトではなく、iOS アプリのデータをドキュメント サーバーと同期するドキュメントとして整理したいと考えています。iOS アプリ用にカスタム調整された iCloud のようなサーバーを展開できたら、どんなにクールでしょうか?!