今後の予定

婆さん拉致計画

要望やアドバイスがあるので、どうにか「婆さん」ことヴァーサタイル(ヴァーサティル)クロック(Versatile Clock)をパクれないか調査中です。
ただ、一生懸命調べてはいるのですが、さすがにADSの婆さんはあまりに複雑で、移植どころか一部機能の流用さえ難しく、苦戦しています。
ヴァーサタイル(多目的)という名が示すように、婆さん内部には、一言でクロック(時計)と呼んでいいのか困るほどの情報が、これでもかというほどギッチギチに詰め込まれています。
それゆえに婆さん(博識、知恵袋的な？)と通称されているのかもしれませんが、これを流用できるようにするとなると一筋縄ではいきません。
生あたたかく見守ってください。

他の呪文じぇねれーたーを探す

婆さんを誘拐する道のり

婆さんは主に次の3つのファイル、プログラムから成り立っていることが判明しています(共有スクリプトファイルやCSSファイル等は除く)。

①コンテンツの描画に用いられるメインのHTMLファイル。
②クライアント側で実行される婆さんのプログラム・コアが書き込まれたスクリプト・ファイル。
③サーバー側で実行される婆さんのプログラム・コアが吐くアップデート用のファイル。

①や②もかなり複雑な構造なのですが、最大の問題は③のサーバーが吐くコードです。
婆さんはDOM等を一切用いていません。
にも関わらず、ページを開きなおすことなくコンテンツが自動更新されます。
IE5.5でも問題なく動作するので不思議に思って調べてみたら、実に興味深い手法が用いられていました。
具体的には、パラント(親)フレームから婆さんのアップデート用CGIをチャイルド(子)フレームで読み込み、そのチャイルド・フレーム内のスクリプトでいくつかの計算を行い、パラント・フレームに更新データを渡していました。
つまり、チャイルド・フレーム内のページがリロードされるたび、CGIの吐き出した新鮮なデータがパラント・フレームへと送られる仕掛けです。
それによって、非同期通信技術への対応が十分ではないブラウザーでも、パラント・フレーム自体をリロードしないでコンテンツが自動更新されるように工夫されています。
単純にコンテンツを部分更新するだけなら、定期的に特定のスクリプト・ファイルを読み込みなおすという方法もあるのでしょうが、ADSのことですから、こういう実装にしたのには何か特別な理由がある※のでしょう。

しかし、ここで問題になるのは、同一ドメイン下でなければパラント・フレームがデータを受け取れない部分です。
POSTなら、ドメインが異なっても受け取れるブラウザーはありますが、その場合でも古いブラウザーではエラーになってしまいますし、そもそも婆さんのアップデート用CGIはパラント・フレームにPOSTする仕組みではありません。
どう考えても、婆さんに関しては、外部ホームページからの完全な流用はできなさそうです。
もともと 外部のホームページで利用させるために作られていない のですから、しかたありません。
そこで、全ては無理でも、アップデートに関わらない部分なら、なんとかなるんじゃないか？というのが今後の課題です。
もっとも、その他の部分だけとはいえ複雑極まる婆さんの解析ですから、それなりのエンジニアが力を合わせたところで相当な時間を要するだろうことは無能な私にも想像できます。
私が生きているうちにはなんとかしたいと思います。

※ 2021年7月追記。
婆さんが、チャイルド・フレームとリロード処理を利用した情報の更新を行う理由について、あることに気が付きました。
定期的に特定のスクリプト・ファイルを読み込みなおす方法では、キャッシュのロードが優先されて情報更新されない事態を回避するために、スクリプト・ファイルのURLにクエリを加え、ブラウザーを欺く(別のファイルと認識させる)テクニックがよく用いられます。
一般的には script.js?20200101010101 のように、クエリに日時を加えたりするのですが、よく考えると、この手法を用いた場合、更新の都度、ブラウザー側に無駄なキャッシュを生み出し続けることになります。
ようするに、更新した回数だけローカル・ドライブの容量を無意味に消費することになり、ブラウザーによっては処理が非常に重くなったりするわけです。
そうした事態を避けるために、婆さんはチャイルド・フレームとリロード処理を利用しているのではないかと思われます。

《十文字じゅもんじぇねれーたー》