モトザヤ

　先日シンプルな形に整えた後、そのとき問題となる点を修正してみたら、恐ろしいことに元に戻ってしまいました。 orz

　整えた点は以下です。

• テンプレートバッファへの自由なアプローチを「レンダーシステム」という抜本的に大きなシステムの交換で行うのではなく、プログラマブルなパイプラインの交換（プログラマブルシェーダ相当）でコンパクトに行うことにした。
• レンダーシステムが具体的なリソースのロード手段を持たずに済むようにした。テンプレートバッファをロードするのではなく、外部からバインドしてからレンダリングに入るようにしてみた。
• 例の妄想に基づき、これらの特性は仮想ハードウェアレベル（コアのプラットフォームの基盤）としてとらえた。

　その結論は、メインシーケンスであり、ソフトウェアで実現するシーケンスであるタスクシステムからアプローチできるのは、ソフトウェアで整理されるリクエスト（オペレーション）レベルという形に……

 　↑ちょっと頭の中を整理するために使った用語（クラス名）がおかしいところはありますが、基本的には v1.0 案の基本構造と変わりません。

　しかし、この繰り返しの中で分かったことがひとつあります。ひとつは、 XOOPS Cube の仕様である「レンダーシステムの交換」は、 "レンダリングのパイプラインの一部の交換" のほうが、ピンポイントで、それをやりたい人の志向に合っているということ。もうひとつは、そのプログラマブルな箇所の交換は、高いレベルではなく、低いレベルでサポートした方が既存物へのオマージュになるということです。この場合、コアとして「不可侵」な部分は「低レベル」で囲んだ部分……すなわち「 XOOPS Cube はテンプレート解釈とレンダリング部分を交換しながら実行できます」であり、そこへどういうアプローチをとるか（＝高レベル部分）は交換可能対象にできるということです。

　従来はここが錯綜していて、コアが用意しているシーケンスが気に入らなければ、交換のアプローチにも乗っかれないという状態でした。今回の整理で、コアのシーケンスが馬鹿らしいから使わね〜〜となっても、低レベルなプラットフォームは残るので仕様は確約されるという構図へ持っていけたのではないかと思います。