資料配信とPowerPoint連携

資料の配信経路

講義中の表示位置はPostgreSQL、PDF本体はPrivate R2で管理する。学生端末とDisplayは講義状態から表示する資料とページを決め、Asset Workerを通してPDFを取得する。画面の映像を転送する方式ではなく、各ブラウザがPDFを描画する構成である。

Asset Workerは閲覧権限と公開状態を確認してからPDFを返す。HTTP Rangeに対応し、ブラウザは必要なバイト範囲を指定して取得できる。ページの変更通知にPDF本体を含める必要はない。

資料の公開手順

資料の追加は、アップロード、公開準備、配信側の有効化、DBへの確定という段階で進める。アップロード済みのファイルが、そのまま学生の閲覧対象になることはない。

R2側のマニフェストは、配信対象のファイルと公開状態を記録する一覧である。DB側の公開台帳は処理の進行を記録する。Edge Functionsが両者の応答を照合し、配信側の有効化を確認した後に、DBの資料一覧と講義の表示状態を更新する。

DBとR2の整合性

DBとR2は独立した保存先であり、両方の更新を一つのトランザクションで確定することはできない。そのため、公開処理の識別、競合する更新の検出、閲覧時の世代照合を組み合わせて整合性を保つ。

配信側の更新だけが完了し、応答が失われると、DBとR2の世代番号が一時的に一致しないことがある。この間は閲覧を拒否し、未確定の組み合わせで資料を返さない。同じIDで再試行すると、配信側の完了状態を確認してDBの確定へ進める。

講義終了後に届いた公開要求は取り消す。取り消しの際も対象資料・世代・ETagを確認し、後続の公開結果を上書きしない。終了・削除の記録は残し、遅れた要求で資料が再び公開されることを防ぐ。

PowerPoint連携

Windows上のPresenter Bridgeは、COMを通じてPowerPointの現在のスライドを観測する。対応するPDFのページ位置をGateway・Edge Functions経由でDBへ送り、ブラウザ操作と同じ講義状態の配信経路へ接続する。

Bridgeは、送信中の位置、次に送る位置、サーバーで確認済みの位置を別々に保持する。送信中にスライドが進んだ場合は、待機中の位置を最新値へ置き換える。通信遅延で操作が蓄積しても、過去の位置を順番に送らず、現在位置へ追従する。

応答を確認できない要求は、未反映とは断定できない。そのため未確認の送信がある間は、現在位置が以前の確認済み位置と同じでも送信を省略しない。DB側では同一要求の再送を識別し、古い連番の更新は拒否する。

接続時に確認したPDFやPowerPointの内容が変わった場合は接続を失効させる。連携対象は対応付けた資料のページ位置であり、PowerPointのアニメーションや動画は配信しない。