私は、Google Wave や Etherpad で見られるのと同じ種類のマルチユーザー、自動保存、無限の元に戻す/再生機能を備えた Web アプリケーションを検討しています (ただし、規模とユーザーベースは大幅に小さくなっています)。
車輪を再発明する前に、これはテクノロジまたはライブラリの一部として、あるいは単なるデザイン パターンとして、すでに対処されているものですか。
おそらく「正しい」答えはないので、これが必ずしも最適なスタック オーバーフローの質問ではないことはわかっていますが、私の Google-fu は失敗しました。読書リストが欲しいだけです!
通常、私は python/django で開発していますが、これは確固たる要件ではなく、好みの問題です :)
本物の技術的なクラブサンドイッチのように聞こえます：
サーバーのWebページサービスとユーザーおよびセッション管理サーバーコード
サーバー内のOLTPおよびCometインスタントメッセージングサーバーコード
サーバーのバージョン管理の競合解決コード
クライアント内部のRAM内バージョン管理データベース
クライアントのバージョン管理の競合解決コード（応答性を高めるために着信バイトでバッチで動作します-クライアントプラットフォームはシングルスレッドです！）
クライアント内部のインスタントメッセージングクライアントコードをコメットします（応答性を高めるために着信バイトでバッチで動作します-クライアントプラットフォームはシングルスレッドです！）
クライアントGUIでのテキスト測定
（オプション）フォントメトリックが十分に理解されていないブラウザ用のカスタムビットマップフォント
クライアントGUIの2Dアニメーションコード（応答性を高めるためにペイントリストでバッチで動作します-クライアントプラットフォームはシングルスレッドです！）
クライアントページのWebユーザーセッション管理サーバーコード
主な設計上の懸念事項は、役に立たないプロキシサーバーや接続または帯域幅の制限のニーズに直面しても、継続的な運用をサポートするためのネットワーク使用モデルの柔軟性です。おそらく、Cometのシグナリング戦略とタイムアウト範囲の非常に多様なスイートを簡単に切り替えて実験し、フィールドでのCometの制限や問題が減ったときにアプリを簡単に拡張できるようにする必要があります。
実装上の主な関心事は、GUIがキャレット位置の変更を受け入れて確認するか、Comet（レイヤー）からの編集とテキスト入力の変更を受け取るまでのイベントの可能な限り短いシーケンスを達成することだと思います。