あるページの AI にコントローラーがあるプロトタイプを作成しています。テレビのリモコンを想像してみてください。別のページ B では、フォーム A とは独立しており、別の画面/コンピューターである可能性があります。いくつかの要素 X、Y、および Z が、ページ A のリモコンによってアニメーション化されます。
私の最初のアイデアは次のとおりです。
これが正しい方向なのだろうか。
これはプロトタイプ用であるため、生産に最適なアイデアである必要はありません。
これにはWeb ソケットを使用できます。
この手法は両方のシナリオで機能する可能性があるため、2 台のコンピューターを使用しており、どちらも Web サイトを指しているとします。
単なるプロトタイプの場合は、ページ B で 5 秒ごとにサーバーをポーリングして、ページ A から送信された更新を探すだけで済みます。
ただし、実際には、何千人ものユーザーがいる運用アプリの場合、これにより多くの帯域幅が消費され、サーバーに大きな負荷がかかる可能性があります. 負荷と帯域幅の使用を補うために、ポーリング レートを 10 秒または 30 秒に増やすことができますが、この変更に応じて、ユーザーはブラウザーがサーバーからの更新を要求するのを待つ間に遅延が発生します。
本番アプリでは、多くの開発者がソリューションとして Comet に目を向けています。コメットは基本的に、リクエスト/レスポンス サイクルを使用してサーバー プッシュをシミュレートする技術に対して Alex Russell が付けた用語です。
一般的な考え方は、ブラウザがサーバーにリクエストを送信し、サーバーがその接続を無期限に開いたままにするというものです。接続は、別のユーザーがサーバーに更新を送信するまで開いたままになります。更新が送信された場合、サーバーは接続しているユーザーに応答を送信します。
Dojo と Jetty チームは、継続を使用する場合、この手法が 20,000 接続まで拡張できることを示すデモンストレーションを行っています。
データベースやいくつかのセッション変数を使用して実験を問題なく実行できると思いますが、PHP での Comet について詳しく知りたい場合は、How to Implement Comet with PHP を参照してください。幸運を！
アップデート：
また、JSON を使用したメッセージの受け渡しについて概念的に考える方法について、あなたは間違いなく正しい考えを持っていると言いたいです。
- JSON を読み取り、トリガーするアクションをリッスンするリスナーをページ B に作成します。
どのアクションをトリガーするかをページに伝えるメッセージを渡すことについて、あなたがどのように考えているかが本当に気に入っています。考えてみれば、メッセージ パッシングの概念を再利用して他のコマンドを呼び出すことができるので、呼び出す必要のある新しいコマンドが発生したときに車輪の再発明を避けることができます。ポーリングするか、Comet を使用するか、WebSocket を使用するかに関係なく、抽象化と汎用的で再利用可能なデータ トランスポートについて考えるのは良い考えです。
cron ジョブを使用して x 単位時間ごとにページ B を実行すると、ページ A から最新の更新された json (ロジックに従ってクエリされた/返された出力) を確認できます。このようにして、ページ A から新しく更新された json を使用して、さらなるタスク...
これは、ポーリング (ページ B がサーバーからの更新を常にポーリングする) を使用するか、サーバー送信イベントや websocket などのサーバー プッシュ テクノロジを使用することで実行できます。
はい、それはうまくいきます。ベクター ライン アニメーションを作成するのと同じ方法で作成することもできます。移動の「コマンド」をサーバーに送信し、それらを (データベース、ファイルなどに) 記録します。クライアント プログラムは、いつでもどこでもスムーズに移動を要求して再描画できます。