home/資料/内部仕様/

ビルトインエディタでの同時多人数編集

Design (TBD)

内部仕様

ライブラリ

  • yjs
  • yjs-codemirror.next
    • CodeMirror v6 に対応
  • y-socket.io
    • socket.io に対応
  • y-mongodb-provider
    • MongoDB 操作に対応

Revision は飽くまでもユーザーの誰かが明示的に保存したタイミングで作られるもの。 History で diff を見られる機能は revision 間で構わない。つまり、yjs で自動で作られたデータは、その時点に戻るためだけに使えればよく、diff には関与しなくてよい。

  • View から操作できるときに対応する
  • tag 更新時など revision が更新される契機を洗い出し、コンフリクト可能性に注意する

DB 保存のタイミングを調整し、自動保存の履歴が大きくなりすぎないようにする

  • オフライン時に作成されたときは
  • ブランチを増やすイメージでいる

TBD

  • edit モードになってから WebScoket コネクションするまでの仕様

    • HackMD のような画面を見せるかどうか > 却下

  • Editor (ydoc) にデータがある場合に View に編集中であることのアラートを表示させるかどうか

    • アラートは表示させない。v6 までよりも、ドラフトが存在するということをもっと軽く取り扱いたい

  • オフライン時の対応について

    • オフライン時の挙動については、今の段階で実験をして方向性を探りたいのはある。View を表示してからオフラインになり、その状態で編集開始できないというのは許容してもよさそうだが、エディタを表示してからオフラインになった場合に HackMD のように編集不可能になる(エコーバックが返ってこないので入力できない)のはなんとかして回避したい。

  • コンフリクトについて

  • オフライン、オンラインがわかるようにする

  • sync しているユーザーがわかるようにアカウントを表示する

いまのところ考えている方針

  • ナレッジベースアプリとして一度入力した内容が消えないことを最優先にする
    • データが消えないという安全寄り
  • オフライン側に制約を設ける

制限

1. オンラインでないといけない

オンライン状態とは？

  • ユーザーが GROWI のクライアントを開くことができ、WebSocket コネクションを GROWI サーバーと張れる
  • 自分の変更と WebSocket コネクションしているほかのすべてのユーザーの変更がリアルタイムで相互に反映される
    • リアルタイムについて: 具体的な数値は定めていない、感覚値で HackMD レベルで進めている
  • GROWI サーバーが DB と連携できており Editor の入力内容や「更新」ボタンの押下によって対象のコレクションが更新されていく

オフライン状態とは？

  • ユーザーがインターネットにつながっておらず、ブラウザから GROWI App クライアントを開けない
  • インターネットにつながっていてブラウザから GROWI App クライアントを開けるが、WebSocket コネクションできない
  • インターネットにつながっていてブラウザから GROWI App クライアントを開けるが、GROWI App サーバーと通信できない
  • インターネットにつながっていてブラウザから GROWI App クライアントを開け、GGROWI App サーバーとも通信できるが、DB と通信できない
  • WebSocket コネクションできているが、リアルタイムに反映されない

TBD

  • 一度コネクションできた後に、コネクションが切れてしまったときの挙動
  • オフラインの後途中でオンラインになった場合

2. コンフリクトしたときは解消しないといけない

コンフリクトが発生するのはどんなとき？

initialValue 同士のコンフリクト

  • 発生条件:
    • TBD
  • 解消方法:
    • TBD

ydoc 同士のコンフリクト

  • 発生条件:
    • TBD
  • 解消方法:
    • TBD

ydoc と initialValue のコンフリクト

  • 発生条件:
    • TBD
  • 解消方法:
    • TBD

y-writings コレクション内でのコンフリクト

  • 発生条件:
    • 同時多人数編集中に複数ユーザーが同じ個所を変更する
    • オフライン時の対応
  • 解消方法:
    • 基本は yjs が持つ CRDT によって解消してくれる（はず）

revisions コレクション同士のコンフリクト

  • 発生条件:
    • TBD
  • 解消方法:
    • TBD

y-writings と revisions のコンフリクト

  • y-writings が先（先とはなにか, timestamp）
    • コンフリクトする場面は「更新」ボタンを押したときに限定される？
      • 基準を timestamp として y-writings が先ならばそのまま y-writings コレクション、つまり ydoc がそのまま revisions を上書きする
  • revisions が先（先とはなにか）
    • コンフリクトする場面は？
      • ★
      • ここで少し内部仕様：initialValue を revisions から取得する。もし ydoc がなければ initialValue を初期値として ydoc に insert し、ydoc の値を Editor に読み込ませ表示する
        • 「ydoc がなければ」とは socket コネクションを張ったうえで y-writings コレクションを参照し、id: pageId を持つドキュメントがないかを探す。これをしても、見つからなかったとき。

この機能によって不要になるもの

  • ページ遷移やブラウザクローズ時に Editor に更新されていないデータがあるときのアラート
  • HackMD 関連
  • 「○○さんが更新しました」のアラート

確認すべきこと

  • メモのような位置づけ。内部仕様
  • 「基本」に書くことは動作確認で確認する。

基本

  • ユーザーストーリーを達成できるか
    • 同時多人数編集できるか
    • 自動保存されるか
    • コンフリクトを解消できるか
  • オフライン時を考慮できているか
  • UI/UX が考慮されているか
  • ドキュメントがあるか
  • テストコードがあるか
  • 不要になった機能を omit できているか

詳細

  • 基本機能/考慮漏れがないか
    • ページを削除した場合は対象の y-writing ドキュメントも削除できているか
    • pageId によって page ドキュメントと y-writings ドキュメントを紐づけているので、page ドキュメントと y-writings ドキュメントのキー参照が必要だが、pageId が変わる場合がないか
    • 自動保存でも誰が更新したか確認できないかどうか
  • 自動保存性が守られているか
    • y-writing のデータはいつまで保存されるか
    • オフライン時でも Editor に入力した内容は保持されるか
    • 他ユーザーによって上書きされた場合に復元できるか
  • yjs の仕様・DB 制約
    • ydoc の update イベントで DB ドキュメントが作成されるはずだがそれはどの頻度か
    • y-writings の clean up/flush db はどの頻度/契機か？ ドキュメントが大量に残って DB を圧迫し続ける可能性はないか
    • 同時編集時にの Undo について、他ユーザーの入力を Undo できるか
    • 何人まで同時多人数編集できるか
  • 内部仕様
    • 図を用いて同時多人数編集と自動保存のライブラリ関係とライフライクルを説明できているか
  • UI/UX
    • Awareness 等のデザインを相談できているか
    • テストプレイを用いて UX を相談できているか
  • GROWI v6 の Editor の機能のうち、保存/コンフリクト解消/アラート等について考慮漏れやがないか
    • 「更新と同時にすべての配下スコープを上書き」機能を洗い出す
    • slacknotification の仕様
      • 「更新」ボタンがおされたら
    • Auditlog、Activity、Action
    • TBD

Commments