次の XOOPS Cube
minahito
次の XOOPS Cube についてこういう計画を立てています。
http://sourceforge.net/forum/forum.php?thread_id=1851725&forum_id=537172
邦訳は、１投目がこちら
http://sunday-lab-ja.blogspot.com/2007/10/next-xoops-cube.html
２投目以降はこちらに書きます。
--------
現在 BASE はデータ構造のほとんどを定義しなければいけません、なぜなら、 XOOPS Cube は主にメソッドの抽象化を交換可能性のために
使用しているからです。そのため、私たちは XOOPS Cube が何を提供する存在なのか掴みかねています。現在の BASE の要件定義（ウェー
ト）は非常に大きく、 BASE はモジュールの一種というよりむしろXOOPS Cube そのものになっています。
次の XOOPS Cube では、ロジックインターフェイスと特にデータ構造の両方を定義しなければならないでしょう。言い換えれば、 XOOPS
Cube は交換可能性のために Vistor などを使用する必要があります。
XOOPS Cube 0.9 は Bridge も Visitor も使っていません。私たちは X2 をエミュレートする Legacy を作ら
なければいけませんでしたので、私たちは XCube に「なにか」を実装するための余裕がなかったのでした。しかし、私たちが次のXOOPS
Cube について考えるとき、それぞれの交換可能プロセスはロジックかデータのどちらかをピンで留めなくてはいけません。
--- 研究開発 ---
XOOPS Cube は局所並行性と非局所的並行性を抽象化する「XOOPS Cube 仮想サービス」を持っています。これは難課で、人類的にもま
だ答えを得ていません。
0.9 では、私は局所/非局所的並行性という観点で考えていませんでした。仮想サービスもシーケンシャル処理の一部と考えていたからです。しかし、私
は仮想サービスを並行処理と表現しました。もし、私たちがこの定義でいくなら、アクターモデルについて調査が必要です。
--- C ---
私は XOOPS Cube は PHP と C の両方で書かれるべきだと思います。XOOPS Cube レイヤーはプロジェクトが唯一それぞれの
ユーザーによる調整を推奨しない箇所です（Cube レイヤーは交換可能性のためにインターフェイスを定義しているので）。それを示すために、プロジェ
クトは C 版を書く必要があるかもしれません。
--- P.S. ---
XOOPS Cube レイヤーが固定された後、 Cube のメンテナにはほとんど仕事がありません。プロジェクトは様々な BASE の持ち込みに
よって進行するでしょう。 BASE プログラマが XOOPS Cube ワールドのメインプログラマです。そのためにも Cube レイヤーは明確
な仕様でフィックスされなければならない。
--------<<ここまで>>--------
現在の XOOPS Cube は単体では実行不可能で、メインループに相当する処理も持って
いない、インターフェイス定義集になっています。いくつかのクラスを除けば、クラス
を継承してロジックを積み、それで動かしてくれ、というスタイルです。
正式版に向けて Cube 側にもそれなりにコードを積み、
Cube がロジックを持つ場合は、オブジェクト側の振る舞いで変更。
Cube が継承不可能なデータ構造を使用する場合は、ロジック側の振る舞いで変更。
Cube が直コールする（継承不可能な）コードパスがあって、データも固定な場合は、
Visitor を使用してこれを交換可能に。
継承も乱用せず、 Cube がロジックを持っておいて、その Impl を交換可能にする。
また１投目に書いたように、デリゲートをコールバックとして乱用せずに、たとえば
ブリッジは Legacy では（コメント管理で）デリゲートを使用していますが、そこは
ちゃんと実装を担当するクラスを定義するなど厳密に進めたいと思っています。
それで最終的には、 BASE 以外のモジュールでは
XCube が定義するスタイルでコードを書いて（プログラマも必ず間に一枚 BASE 対応
を挟むようにして BASE への依存性を殺せる構造にしておいて）、あとは BASE の
手続きに従ってそれがサイトに配置される部分を書く...ということを想定しています。
頒布物としては流用効かないかもしれないけど、クラス単位では再利用可能にする、と
いう書き方を可能にする。 BASE も XCube が定義するその手続き上で作ってくれ、と
いう形です。
のぶのぶ
On 11月3日, 午前11:08, minahito <minah...@gmail.com> wrote:
> minahito です。
> 次の XOOPS Cube についてこういう計画を立てています。
>
> http://sourceforge.net/forum/forum.php?thread_id=1851725&forum_id=537172
>
> 邦訳は、１投目がこちらhttp://sunday-lab-ja.blogspot.com/2007/10/next-xoops-cube.html
>
> ２投目以降はこちらに書きます。
理解するのにかなり時間かかりそうですが・・・一歩ずつ牛歩のように、反応していきます。
（本来、この会話をするために、このグループ開始したようなものですが・・・）
まずは、ブログ内の、1投目の最初部分から・・・
「同意」「疑問・反論」「評価不能」に分けながら少しずつレスしていきます。
> XOOPS Cube controller は、 XOOPS の冠を自らに与えんがために X2 のシークエンスを見すぎました。
「同意」：この事は、旧Dev-MLでも何度か話題になったと思います。
特にexecuteCommon部分の初期化部分の扱いなど顕著にX2を見過ぎています。
> Cube は OGRE にインスパイアされたのですから、私たちはコアをもっと OGRE に近づけるべきでした。
「評価不能」：近づける先のORGEを具体的には知らない以上は評価しようが有りません。
> Cube はオブジェクト指向設計の表面に囚われています。
> (snip)
> 私たちはもっと伝統的な技術を使うべきでした。
「疑問・反論」：トレンド・伝統的というインプリ論の前にコアシステムが、
持つべき機能を明確にする必要が有るのでは無いでしょうか？
その機能実装の為にどのような技術を使用するかという流れにならないと、
議論が前に進まないような気がします。
コアがウェブをどの程度スコープとするのかについても、開発者間にかなり
温度差が有るような気がします。（これについては、後述します）
> 最新の Web 開発のトレンドは「迅速な開発」ですが、私たちのトレンドは知識を
> オープンワールドで共有するための「モジューラブル設計」「換装可設計」であるべきです。
「同意」：共有するための「モジューラブル設計」「換装可設計」を目指すべきだと言うことは同意です。
「疑問・反論」：これと、「迅速な開発」は相反するのでしょうか？「お手軽な開発」という意味なら
相反する可能性は有りますが・・・
> そのために、ウェブアプリケーションはシーケンシャルな処理ですが、私たちはいかにそのシーケンシャル
> 処理を構築するかについて考慮するべきです(snip)
「疑問・反論」：「そのために」は、「モジューラブル設計」「換装可設計」のためにととらえたら・・・
「ウェブアプリケーションは」と来てるんで混乱しています。
> XOOPS Cube における開発はいつでもどこでも優れたツールとともにあるべきです。
「同意」：はい、その通りです。
----------
とりあえず、ここまでのコメントは重箱のスミ的つっこみも多いですけど、
明日も、もう少し、1投目の後半部分についてはコメントしようと考えています。
が・・・・小生が、XCube開発当初から気になっている点は、CoreとBaseの境界面です。
基本的には、XCubeでは、Core＋Base(+Module)にて、最終的にエンドユーザの目に触れるシステムとして
成立します。（ModuleはX2の概念なので必要かどうかは最終的にBaseが判断すれば良いことと考えられます）
XCube Legacyでは、おそらく本来のBaseとX2互換を維持するべきユーティリティプログラムが合わさって、
LegacyモジュールになっているのでBase自体が持つべき機能もグレーになっていますが・・少なくとも
この集合体によってCMSというアプリケーションシステムになっているわけです。
で、この前提でCoreは、Baseに対して何を提供するべきなのでしょうか？
（現行の0.9が何を提供しているかという事ではありません）
ORGE的に言うと「何も具体的なものは提供しない」という答えが返ってきそうですが、少なくとも
ORGEは、「Object-Oriented Graphics Rendering Engine」の略称であり
> OGRE is a scene-oriented, flexible 3D engine written in C++ designed to make it easier
> and more intuitive for developers to produce applications utilising hardware-accelerated 3D graphics.
という説明に有るとおり少なくとも3Dエンジンであるという歴然とした、目的と用途を持った上で、
そのコアとしてどうあるべきかという考え方が根底には有るはずです。
この「scene-oriented, flexible 3D engine」に相当する部分、XOOPS Cubeはなんと説明するのかによっ
て、
Coreがどういう機能を最低限持つべきかという答えを導いていくべきだと思います。
その上で、そのCoreを利用するBaseのデザインガイドがドキュメントとして整備されることによって、
新たなBaseの出現を産むことができるのでは無いでしょうか？
今、おそらくこの開発コミュニティーに集まっておられる多数の方は、やはりWEBというキーワードが
頭に有ることと思いますので、この観点から考えると
XCube Coreは、Baseに対して、
・Webアプリケーションを構築するに当たっての基盤となる技術要素のクラス群およびフレームワーク
を提供する。
というのが、一般的な考え方になるのではと思いますが・・・
この「基盤となる技術要素」として具体的にはどのようなものをノミネートし
その実装にはどのようなパターンや手法を使用するという実装設計にすすんでいく
形でロードマップを整理していった方が、皆の理解を深めやすいような気がします。
とりあえず、今日はここまで・・・・
Tom Hayakawa
この絡みで、ちょっとだけ・・・。
＃ほんとは、XCDMでもこれを言いたかったんだけど・・・。
Xcube は、そろそろ、独立したプロジェクトとして、CVS上で別モジュールとしませんか？
XOOPS Cube にこれだけの変更を加えるという事は、
Legacyにも対応させるならば、少なからず変更を加える必要があると思います。
Legacyが常にXOOPS Cube の最新版に対応しているならともかく、
実際には、その対応にタイムラグが生じる可能性もあるでしょう。
また、現在、新しいBase開発のプロジェクトがあるようですが、
それらのbase は、XOOPS Cube のどのバージョンがベースなのか、
これ、開発者にとって結構重要な事だと思います。
そういう意味では、XOOPS Cube のバージョンだけでもハッキリ出来る形があるべきかと思います。
更に、様々なbase開発を促進する為にも、独立した形があるべきかと思います。
個人的な話で恐縮ですが、
最近、名古屋のＯＳＳ関連の開発者の方々にXOOPS Cube の紹介をする機会が多々あるのですが、
その時に、「興味のある方は、ぜひXOOPS Cube をお試しください・・。」
「ダウンロードは・・・・えぇ～～と・・・、」
「XCLをダウンロードしていただき、その中のCore を抜き出して・・・」
それはないよね。^^;; 説明し辛いです^^;;
まぁ、僕の個人的な話は別にしても、^^;;
そろそろ、CVS上で別モジュールとして、単独でダウンロード可能な状態にしても良い時期では無いかと思いま
すが、どうでしょうか？
NobuNobu
Tom Hayakawa さんは書きました:
> Tomです。
> Xcube は、そろそろ、独立したプロジェクトとして、CVS上で別モジュールとしませんか？
はい、小生もそう思います。
現在のLegacy_Packegeのcoreを直接変えるのは危険ですね。
core1.0にいたる試行錯誤は、クローズした形で行ったほうが、
Legacy側の対応も、core1.0の仕様がFIXした段階で、一気に
取り掛かれるので、安全かつ効率的だと思います。
minahito
すみません、 nobunobu さんへのレスは晩にでも...
（むちゃくちゃ長文になってしまい、見直してます）
で、こちらですが:
> > Tomです。
> > Xcube は、そろそろ、独立したプロジェクトとして、CVS上で別モジュールとしませんか？
>
> はい、小生もそう思います。
> 現在のLegacy_Packegeのcoreを直接変えるのは危険ですね。
これは自分もそのつもりでした。
sf.net にカキコしておきます。
minahito
お疲れ様です。
まとまったようでまとまっていませんが、ひとまず前半部のレスです。 ^^;
# このスレッドは重要だと思うので、後日英訳して sf.net にあげておきたいと思います。
> > XOOPS Cube controller は、 XOOPS の冠を自らに与えんがために X2 のシークエンスを見すぎました。
>
> 「同意」：この事は、旧Dev-MLでも何度か話題になったと思います。
> 特にexecuteCommon部分の初期化部分の扱いなど顕著にX2を見過ぎています。
はい。これはぜひ見直したいと思います。
> > Cube は OGRE にインスパイアされたのですから、私たちはコアをもっと OGRE に近づけるべきでした。
>
> 「評価不能」：近づける先のORGEを具体的には知らない以上は評価しようが有りません。
先の書き込みはすべて英語版の邦訳ですので、たとえば OGRE の設計など http://www.ogre3d.org/
に行けば分かることは割愛させていただきました。
日本側のフォローはまた別途考えますし、説明の中に混ぜるなどして OGRE のことも伝えていきたいと思います。これまでは OGRE OGRE
でしたが、ここにきて OGRE とも「どう違うのか」も論点に含めなくてはいけなくなってきましたし。
> > Cube はオブジェクト指向設計の表面に囚われています。
> > (snip)
> > 私たちはもっと伝統的な技術を使うべきでした。
>
> 「疑問・反論」：トレンド・伝統的というインプリ論の前にコアシステムが、
> 持つべき機能を明確にする必要が有るのでは無いでしょうか？
> その機能実装の為にどのような技術を使用するかという流れにならないと、
> 議論が前に進まないような気がします。
原文で主張したかったことは、インプリ論というより、外野プログラマが Web PHP
でコードを書いて行く上での心構えというか、コーディング方針のことです。簡単に言うと Web/PHP
は柔らかく、崩して書く新人類向けの分野だけど、真似できないものに付き合う必要は無いから、伝統的な方法を堂々と胸を張って使いましょう、というものです。
以下に原文でも言及したケースも含めて例示しますと...
(1) デリゲートの乱用
デリゲートは今、 Observer というより Hook と認識されています。また、 Clear() を積むことで State
の仕事をこなすことが可能になっており、 Legacy の一部（コメントハンドラ等）では Bridge、
XCube_PageNavigator では（サブクラス定義数を押さえるために）関数ポインタとして使われています。
（この「関数ポインタとして便利」というのは、関数ポインタがない C# でもそう使われているところはあるのでしょうがないですが）
(2) 変態 FSM
切り分けとしては、cubson の問題ですが、
Legacy の ActionFrame は mojavi → mojaLE → cubson と順調に変態化した FSM
になってます。しかし元祖 mojavi が有限状態を正面切って FSM
でアプローチしていたか、というと、既にこの時点で変形していたと思います。
Legacy の ActionFrame では、 ?action=
の遷移後のトリガーは基本的に規定の４種類。そのままビュー専用のアクションにしか「遷移」せず、抜け切ります。これは FSM
をアレンジしたというより、「そのまま使わなければ Web/PHP っぽくなる」みたいな考えをもって、結果 Strategy
に変化したものだと思っています。
（天才に変人は多いが、変人になっても天才になれるわけではない。 web/PHP に変態は多いが、変態をやっても Web/PHP になるわけではない）
あの mojavi の変形 FSM
ですら「かなり古い」らしく、最近のWebフレームワークでは、それぞれさらなる独特の解釈や工夫がなされ、フレームワークユーザーはそこを楽しんでいる節があります。
(3) 結論（原文）
Web/PHP は言語を柔らかく使っていくものらしい→「柔らかく使う」のがトレンド。
しかし、それは新人類の感覚で、どうせ僕（ら）には分からない感覚なのだから、だったらきちんと組みましょう、という方針提案です。
インプリ論より前の段階の設計方針のことです。
「具体的にどう組むのか」ということは、もちろん、実装内容が決まるまでは決めません（＝決められません）。
---(一息おいて）---
ただ、この方針は大きいと思います。
XOOPS Cube 層に関しては「新人類の感覚は分からない」ことを理由に、 Cube
層に具体的なロジックを積むことを避ける一方で、中途半端に真似もしてましたが、この方針下では「外部の技術でも骨組みのしっかりしたものは堂々と胸を張って取り入れる」ということになります。
# 「中途半端な真似をしたのも、新方針を打ち出してるのもお前やろ」
# という突っ込みは勘弁してください。三日前の自分は他人です。
これが、タスク技法（ジョブコントローラ）や、レンダリングのコマンドキュー（これについては詳しくは後日）の提案根拠にもなってます。
（理解していないか、そもそも一般化されていないかもしれない）Web
の共通認識におもねるのではなく、プログラム一般の共通認識におもねよう、という話です。僕としてはインプリ論ではないと思ってます。
> > 最新の Web 開発のトレンドは「迅速な開発」ですが、私たちのトレンドは知識を
> > オープンワールドで共有するための「モジューラブル設計」「換装可設計」であるべきです。
>
> 「同意」：共有するための「モジューラブル設計」「換装可設計」を目指すべきだと言うことは同意です。
> 「疑問・反論」：これと、「迅速な開発」は相反するのでしょうか？「お手軽な開発」という意味なら
> 相反する可能性は有りますが・・・
僕は相反すると考えています。
ライブラリと異なり、完全なるモジュールを書く行為は、「動けばいい」プログラムを書くことよりはるかに手間です。また、これは「基底処理にあたるものはコードジェネレータが持ち、生成されたコードをどんどんこねる」という最近の
LL 言語による Web 開発スタイルに反していると思います。
Web/PHP 以前に、共通認識の確認として...僕は「再利用」というと、
Lv. 松) 既存のソースコードをぶっこぬいて次のプロジェクトで使う
Lv. 竹) C++ ならクラスになってるので、多少ぶっこぬきやすいがぶっこぬくことには変わりない
Lv. 梅) ライブラリ化
Lv. ガンダーラ) モジュール化
(*)ガンダーラ...どこかにあると言われているが行き方が不明のユートピア
というのが現実ではないかと思っています。
Windows などではコンポーネントの概念があるのでまた事情が違うのでしょうが……
最近は、スレッドに投げ込むことで起動＆稼働するスタイルのモジュールもあります（←僕がモジュールで想定しているのはこれ。ランタイム・システムに投げ込めば自動で稼働までこぎつける）が、世の中的には「無条件にスレッドｘ個を持っていかれるので使いにくい」「チューニングがきつい」「この制約では再利用できても嬉しくない」と、たいへん不評です。
作る側にしてみても、こういった「モジュール」のプログラムでは、
・とりあえず動くプログラムでは不要なコードの大量執筆
・スタイルの合わせに余計な時間
を行う必要があります。ところが、次のプロジェクトに、メモリ的・速度的・効率的に合致するパーツになるとは限らない……それどころかモジュールを組み込むランタイム・システムが異なるかもしれない。
orz
ということで、「遠くのガンダーラより、近くの梅 or 竹」になるのではないかと……
なので、こういうのは、作る方も使う方もモジュール教に入信しないと価値を見いだせないものではないかと思います。
（「迅速な開発」などといった一般的な価値観を適応できない）
なので、僕の認識としては、
XOOPS2 や、今回 XOOPS Cube
が想定している「突っ込むだけでよろしく動作し、生産性にも恩恵がある【モジュール】」という定義からはガンダーラの歌（その国の名はガンダーラ
どこかにあるユートピア どうしたら行けるのだろう～）は聞こえてきても、生産性アップの歌は聞こえてこないという感じです。
ですから、 XOOPS Cube
関連の開発者は、「自分が再利用すること」よりむしろ「他人と共有すること」にモチベーションを見いだして貰う必要がある、と思っています。
XOOPS Cube をみても、モジュールによる外部への API 放出は Web サービスっぽいものを書いて行うのが正道となってます。「
include して global の function を call する」じゃダメ、ということになっているワケで……
でもこれで「迅速な開発」な武器になるというなら、さっそく宣伝リストに組み込みますのでぜひレビューしてください。(^^)
> > そのために、ウェブアプリケーションはシーケンシャルな処理ですが、私たちはいかにそのシーケンシャル
> > 処理を構築するかについて考慮するべきです(snip)
>
> 「疑問・反論」：「そのために」は、「モジューラブル設計」「換装可設計」のためにととらえたら・・・
> 「ウェブアプリケーションは」と来てるんで混乱しています。
これは次のような意味で受け取ってください。
1) Web アプリケーションも所詮シーケンシャルな処理なので、タスク技法（ジョブコントローラ）でプログラミングできる。
2) タスク技法は抜き差しがたやすい技法なので、モジューラブル設計をタスクの抜き差しでとらえる（それを Cube 層で定義する）ことができる。
ＰＣ（プログラムカウンタ）がどのようなコードパスを巡るかを Cube が制御するなら、 BASE
も開始ジョブと終了ジョブを提供する存在でしかなく、格別に巨大な存在ではなくなります。ジョブリストの積み方が「モジューラブルか否か」を握ることになるから、それを考えましょう、という感じです。
タスク技法では「どのタスクをどうリストするか」"だけ"で大規模プログラムの開発が可能です。
この技法は、ジョブコントローラとして発案されて以来、３０年以上の歴史を持ちますが、現在でも重宝されるテクニックです。もともとは CPU
パワーを使い切るためのテクニックでしたが、柔軟性と交換性に大変優れていることが現代でも愛される理由だと思います。
しかし、「テクニック」「技法」と呼ばれるように、実際にどういう実装をされているかは会社どころか人によってバラバラで、Ａさんが書いたタスクをＢさんのランタイム・システム（タスクシステム）に突っ込めるわけではありません。ここを
XOOPS Cube で定義し、
1) サブシステムの構築柔軟性は従来どおりとして、
2) モジュールの構築柔軟性はタスクリストの作成で受け持つ
形にしたいわけです。
2) を持ち込むために、
「Web/PHP はシーケンシャルなプログラムである」
「シーケンシャルなプログラムにおいてタスク技法は有益である」
「だから、 Web/PHP にタスク技法は有益である」
の三段論法をぶったわけです。
細かいことを言うと二段目の論法を成立させる根拠として「Webのトレンドにとらわれず、伝統的な...」という最初のくだりがあるわけです。
だんだん、通じなかったギャグを細かく解説するお笑い芸人みたいになってきて悲しいので、後半はポストを改めます。 (--;;
--
minahito (mina...@gmail.com)
minahito
後半です。
> が・・・・小生が、XCube開発当初から気になっている点は、CoreとBaseの境界面です。
(snip)
> で、この前提でCoreは、Baseに対して何を提供するべきなのでしょうか？
> （現行の0.9が何を提供しているかという事ではありません）
> ORGE的に言うと「何も具体的なものは提供しない」という答えが返ってきそうですが、少なくとも
> ORGEは、「Object-Oriented Graphics Rendering Engine」の略称であり
> > OGRE is a scene-oriented, flexible 3D engine written in C++ designed to make it easier
> > and more intuitive for developers to produce applications utilising hardware-accelerated 3D graphics.
> という説明に有るとおり少なくとも3Dエンジンであるという歴然とした、目的と用途を持った上で、
> そのコアとしてどうあるべきかという考え方が根底には有るはずです。
再三の主張になってしまうのですが、XOOPS Cube コアの切り分けでは、 OGRE
コアには「コアからサブシステムに提供する機能は無い」と言わざるを得ません。 OGRE コア（プラグインを外した部分）には
scene-oriented 能力も 3D 能力もありません。ポリゴンの表示すらできなければ、３次元上の計算を行う能力もありません。
僕自身 OGRE のポートにコントリビュートするために、 OGRE のソースを全部読み切って衝撃を受けました。
利用者はあくまで「サブシステム」にその「３Ｄ」機能を求めます。OGRE
コアは指定されたサブシステムを構築して「環境」を作り上げる立場です。恐ろしいことに実は OGRE
では、サブシステムの構築自体がサブシステムで行われています。OGRE プロジェクトの説明では、サブシステムを全部引いた後に OGRE
に残るのは Root という Singleton かつサブシステムのコンポジットである Facade ということになってます。
> この「scene-oriented, flexible 3D engine」に相当する部分、XOOPS Cubeはなんと説明するのかによっ
> て、
> Coreがどういう機能を最低限持つべきかという答えを導いていくべきだと思います。
Ogreがそのようなフレーズを出していて、 Cube は出していないというのは、お互いのコア部の設計上の問題ではなく、プロジェクト運営上の問題です。
OGRE が、サブシステムなしではスッカラカンのエンジン（というかエンジンルームか？）で OGRE であれるのは、単純にシステムの定義が
XC と異なっているからです。XOOPS Cube と OGRE のプロジェクト運営に対する姿勢の違いがここに出ているんです。
OGRE の場合は、「サブシステム込みで OGRE」であり、「OGRE が提供する機能」＝「OGRE コア＋すべてのプラグイン」なのです。
XCDM のスライド:
http://homepage.mac.com/minahito/.Public/XCDM_01_OGRE.pdf
で、 OGRE コアは内/外を区別しないと書いてますが、確かにマインド的にはそうなのですが、リポジトリにホストし、コアメンバーが責任をもっていないサブシステムに関しては
Features に載ってないんです。
逆に言えば、 Features に載っている機能の 99% がサブシステムによるものです。
Features:
http://www.ogre3d.org/index.php?option=com_content&task=view&id=13&Itemid=128
サブシステムをすべて抜いた状態を Ogre コアと呼ぶならば、実際には"scene-oriented, flexibility 3D engine"は、
"scene-oriented なサブシステムを使いたい flexibility であることは確定している 3D サブシステムを使いたい engine"
になります。恐らく Ogre の開発陣はコアはサブシステムを成立させるための「おまじない」程度にしか考えていません。
一方、XOOPS Cube ではプロジェクトがガバナンスを行わないため、 XOOPS Cube
の機能は純粋にコア機能しか書けません。したがって機能リストには "flexibility" しか入らないことになります。
もちろん、そういう意味では XOOPS Cube も
"node-oriented でありたい flexibility であることは確定している Contents Management
をしてみたいと思っている system"
を縮めて
"node-oriented flexibility contents management system"
等とホームページ上で記載することは可能ですが、あくまで宣言上の問題であり、これを宣言したからといって、プログラムになんらかの影響を及ぼすものではないと思います。
# OGREは直指定のサブシステムも結構持っていますので、
# どこまでを OGRE 提供機能とするかはこちらの解釈ひとつですが、
# コア（メインシステム）の機能でないことは確かです。
プログラム的には、プラグインアーキテクチャを実現することがコアの仕事……ということで OGRE と XOOPS Cube
の立ち位置は同じです。あとは、体制面で、セントラリズムを選んだOGREと、アナーキズムを選んだ XOOPS Cube の
"ホームページ上の表記方針の違い" に過ぎないと思っていますが...
どうでしょう？
>
> XCube Coreは、Baseに対して、
> ・Webアプリケーションを構築するに当たっての基盤となる技術要素のクラス群およびフレームワーク
> を提供する。
> というのが、一般的な考え方になるのではと思いますが・・・
自分としては、
・フレームワークというのは好き嫌いが激しい環境である
・XOOPS Cube の換装機構はあくまでエンドユーザーのためであってプログラマのためではない（プログラマはむしろ苦労を買う側）
・PHP自体がWebを処理可能
といった点から、わざわざ「Web アプリケーションフレームワークとは何ぞや？」という課題に接して、 Web フレームワーク戦線に飛び込む必要はないと思います。
結局 Web だろうがなんだろうが、少なくとも PHP に関しては、
1) プログラムを実行し、結果をメモリに格納する（メモリを更新する）
2) 1) の結果を使って画面を更新する
の 1) → 2) の一般的なプログラム処理の枠を出るものではないと思います。
たとえば、今回僕は「一般的に理解を得られると思われるプログラマの間では知られているシーケンシャル処理の抜き差し機構」としてタスク技法を推しています。
タスク技法は７０年代オペレーションシステムのジョブコントローラがベースで、３０年近くプログラマの間でさまざまな形で継承されています。もとは
CPU のパワーを使い切るための技術ですが、タスクリストの構築・抜き差しで簡単にプログラム全体の挙動を変更可能な点も重宝されてきました。極めてモジューラブルです。
PHP Web に、これに相当する歴史と実績と知名度を持った、一般化された処理技法はないと思いますし、 Web
だからといってタスク技法などの古典的（かつバリバリ現役の）技法の有効性が損なわれるとは思えません。
（ただ XOOPS Cube のような特殊なシチュエーションがなければ必要性がないだけで）
処理がシーケンシャルであり、各担当からプログラムが提出されて全体の動作を決定するという機構でさえあれば、アプリ、Web、ゲーム等の間に根本的な違いがあるとは思えません。大きく違うのは、その部分が隠蔽されるイベント駆動アプリ（のプログラマ）くらいではないでしょうか。
それならば混沌の Web フレームワーク戦線に参加して「XOOPS Cube はこの Web
フレームワーク」というものを出すより、むしろプログラムの原理原則に返った「伝統的な技法」を用いた方がいいと考えています。
長くなったのでレスを簡単にまとめますと、
「Webアプリケーションを構築するに当たっての基盤となる技術要素のクラス群およびフレームワーク」
は Base にお任せして、 Cube 側は、
「Baseを入れ替え、Baseを他のモジュールのうちのひとつとしてとらえるためのフレームワーク（実行時実行内容制御システム）」
を持つべきかと思います。
--------------------------
ここまで読んで気が付いたのですが、僕は「機能」に関して一般の共通認識を知りません。僕の仕事では「ナントカ機能」というのは、「ユーザーエディット機能」とか古くは「パスワードコンティニュー機能」など、現在では「モード」とか「システム」に置き換えられるユーザー向けのサービスを意味しています。
よくよく考えてみれば、プログラムの「機能」というのは触れたことがない概念なので、定義が分かりません。 orz
ここでいう「機能」とはどういう意味合い・定義のものなのでしょうか？
それが理解出来れば、僕の方から目標の機能リストを列挙できるかもしれません。
--------------------------
> この「基盤となる技術要素」として具体的にはどのようなものをノミネートし
> その実装にはどのようなパターンや手法を使用するという実装設計にすすんでいく
> 形でロードマップを整理していった方が、皆の理解を深めやすいような気がします。
ひとまずここまでのところで、まとめますが、
（理解していただける説明になっているかどうかはともかく orz）
僕は Web アプリを提供するための「具体的」機能を XOOPS Cube に積み込むのではなく、
1) 今回のプログラムは結局、起動→メモリ更新→画面出力（更新）にすぎない
2) XOOPS Cube の仕事は BASE の実装を助けることではなく、 BASE や RENDER の交換を規定することである
（つまりアプリケーションフレームワークとして Web に特化した特別な論理を持っているわけではない）
という主張をもう一度行いたいと思います。
1) はどれもそうですが、 1) にフレキシビリティを持たせるために 2) を徹底するというフレームワークは（PHPでは恐らく）珍しいと思います。
Cube コアは BASE やモジュール、サブシステムを存在と交換を規定する役割であり、Web アプリの実装を助けるコードセットではないという立ち位置です。
逆にもし、 XOOPS Cube が単なる Web
アプリケーション開発フレームワーク（乱戦の中のひとつ）なのであれば、自分がお手伝いできること何ひとつありません。 orz
ただ、原文の２投目にあるように、データ型は積極的に継承不可能な形で定義して、その巡回部を Visitor にするとか、
・あるシークエンスにおいてロジックかデータ型（オブジェクト）のどちらかを固定にする
などの方法でなんらかの（Web非限定の）フレームワークを持つ、というのは必要だと思います。
これらは XOOPS Cube が XOOPS Cube たるために必要な箇所なので、一般的な Web
プログラマ能力とは別の面が求められるため、僕などでも実装が可能だと思います。
自分が考える Cube のフィーチャー（機能ではない）は、
1) 具体的機能は全てサブシステムが持ち、全サブシステムは交換可能である
2) 設定ファイルによって、 1) による起動環境がユーザーの手元で確定する
3) XCube のクラスを直接利用し、間に一枚入れることで、特定の BASE への直接依存性のないクラスを開発可能
4) BASE 非依存処理、組み合わせ自由な処理の代表格として仮想サービスを持つ
5) モジュール間通信の統一手続きを規定する（デリゲート）
6) Base も結局は Cube が規定するタスクのひとつである。つまりランタイム時点の「モジュール」は Cube が規定する
（Cube コアは Base の開発の手間を軽減するためにある程度のコードを持っているが、 Base の Web アプリ開発を支援しているわけではない）
くらいかなと思います。6) が NEXT XOOPS Cube の追加分で、結果として 3) が強化されている部分です。
その観点からは、
・アクションフォームはインプットの観点で捕らえる
・ページナビは XCube 層としては極めて異質
というのがあります。
いや正直、最近、 XOOPS Cube がアクションフォームを持ったのは設計ミスだったかもしれないという気が...
ただ、あれは仮想サービスのような「仮想コンテキストスイッチ」の中でも正しく動くものに進化させれば Cube が格納するべきクラスになるのですが。
--
minahito (mina...@gmail.com)
minahito
> ただ、原文の２投目にあるように、データ型は積極的に継承不可能な形で定義して、その巡回部を Visitor にするとか、
>
> ・あるシークエンスにおいてロジックかデータ型（オブジェクト）のどちらかを固定にする
>
> などの方法でなんらかの（Web非限定の）フレームワークを持つ、というのは必要だと思います。
この部分を説明するコード（動きません）を書いてきましたので添付します。
このプログラムでは、
class XCube_Task
{
...
function draw(&$collector){...}
}
なタスク（ジョブと命名されるかもしれない）のインスタンスを巡回して、
XCube の final class であるコレクターがレンダーターゲットを収集してまわり、
共通の処理でレンダリング工程に入ります。
このとき、コレクターが内部の情報の整理で使うクラス群を BASE は拡張でき
ません。これによって、「 BASE と無関係に、モジュール側で描画を行う手続きは
一緒」になります。デリゲートの使い方が BASE によって異ならないのと同様に...
これは別に Web アプリケーション開発にとっては便利でもなんでもないものです。
元を正せばレンダーシステムやレンダーターゲットという仕組み自体が本来不要です
から...
しかしモジュールのBASEまたぎ流用を容易にしたり、BASEがレンダーシステムを
強制"できない"仕組みの構築には一定の役割を果たします。
--
minahito (mina...@gmail.com)
のぶのぶ
とりあえず、手短に、ポイントレスです。
> ここでいう「機能」とはどういう意味合い・定義のものなのでしょうか？
>
> それが理解出来れば、僕の方から目標の機能リストを列挙できるかもしれません。
いやぁ・・・業界が違うと「機能」という言葉に対してさえも、共通認識がもてないものだとは考えてもいませんでした。
> ユーザー向けのサービス
という言葉を書いておられますが、「そのプログラムが対象とするものに対してできるサービス」的な意味合いで書いておりました。
ゲームとか一般のアプリケーションとかの総体で考えると、対象が「ユーザー」になるので「ユーザー向けのサービス」と
言うことになりますが、コアという位置づけでいうと、
・コアの周辺層（と呼ぶか上位層）向けに提供するサービス
・コアの周辺層（と呼ぶか上位層）の開発者向けに提供するサービス
の総体と言うようなつもりで書いておりました。
> 自分が考える Cube のフィーチャー（機能ではない）は、
>
> 1) 具体的機能は全てサブシステムが持ち、全サブシステムは交換可能である
> 2) 設定ファイルによって、 1) による起動環境がユーザーの手元で確定する
> 3) XCube のクラスを直接利用し、間に一枚入れることで、特定の BASE への直接依存性のないクラスを開発可能
> 4) BASE 非依存処理、組み合わせ自由な処理の代表格として仮想サービスを持つ
> 5) モジュール間通信の統一手続きを規定する（デリゲート）
> 6) Base も結局は Cube が規定するタスクのひとつである。つまりランタイム時点の「モジュール」は Cube が規定する
> （Cube コアは Base の開発の手間を軽減するためにある程度のコードを持っているが、 Base の Web アプリ開発を支援しているわけではない）
>
> くらいかなと思います。6) が NEXT XOOPS Cube の追加分で、結果として 3) が強化されている部分です。
という場合に、
・Base開発者がBase開発する際に XCube Coreをベースにすることによって、
一からスクラッチで開発するときに比べて、どういったメリットが享受できるのか？
という点が、もう少しわかりやすくなれば良いだけかもしれません。
minahito
おつかれさまです。
> いやぁ・・・業界が違うと「機能」という言葉に対してさえも、共通認識がもてないものだとは考えてもいませんでした。
「伝統的な技術」の定義も早くも怪しいかもしれませんね。(^^;
> ・Base開発者がBase開発する際に XCube Coreをベースにすることによって、
> 一からスクラッチで開発するときに比べて、どういったメリットが享受できるのか？
>
> という点が、もう少しわかりやすくなれば良いだけかもしれません。
ありがとうございます。
では「XOOPS Cube ワールドの特徴（妄想編/目標）」という感じで...
[for User]
・モジュールを組み合わせてサイトを作ることができます
・たくさんのテーマから外観を選択できます
・プリロードでモジュール間連携やサイトのカスタマイズを行うことができます
・JavaScript ウィジェットを貼り付けることができます
・専用ツールを使用して、モジュールの選択、ダウンロード、アップデート情報の受信、自動ＦＴＰ転送を行うことができます
・専用ツールはモジュールの依存関係を自動的に解決します
・Web サービスを通じて外部のサイトと連携できます
・各国にコミュニティがあります
・ドキュメントとチュートリアルがあります
・ヘルプがついています
・ディストリビューションパッケージで簡単にサイトをスタートできます
[for Expert User]
・プリロードを使用して、プログラム直修正を行わずにある程度の挙動変更が可能です
・本来連携していないモジュール同士をプリロードで結合できます
・プリロードを使うことでアップデート時の変更上書きを防ぐことができます
・構成ファイルを編集することで、サブシステムの構成を自在に変更できます
・PHP の文法は LL 言語の中でも、Ｃ/Javaに近いため、これらのプログラマはカスタマイズを直観的に行うことができます
[for Gyouha]
・豊富なモジュールを使用してサイトのひな型を作ることができます
・BASE を開発・交換できるため、ＣＭＳ押し付けの仕様に従う必要はありません
・レンダーシステムを開発・交換できるため、ＣＭＳ押し付けのテーマフォーマットに従う必要はありません
・仕様未決事項をデリゲートしておくことで、機能の変更に対応しやすくなります
・構成次第でGPL以外のライセンスをとることができる可能性があります
[for ModuleDeveloper]
・豊富な開発ツールで開発を行うことができます
・BASE が開発できるため、母艦ＣＭＳのアホ仕様変更を警戒する必要はありません
・サービスとデリゲートによってモジュール間連携の手続きがコアレベルで規定されています
・プリロードによる拡張を担保することで、エキスパートユーザーの要望を実現しやすくします
・XCube がビジネスロジックのコールバックと画面出力の手続きを統一しているため、BASE間でのコード再利用性が高まります
・BASE パッケージがサイト管理、ユーザー管理などの基本機能の積んでいるため、アドオン機能/交換機能に専念できます
・各 BASE のシステム気味のモジュールを開発することも可能です
・マルチデータベースが BASE より提供されます
・コミュニティからフィードバック:レポート、パッチ、翻訳、コード協力を得ることができます
・サブシステムに関連するモジュールをプロジェクトに持ち込むことで、プロジェクトコミュニティのフィードバックスキーマを利用できます
[for Base Developer]
・サブシステムの交換、拡張を実装する必要はありません（っていうか実装禁止）
・モジュールビジネスロジックのコールバックを実装する必要はありません（っていうか実装禁止）
・画面出力プロセスをイチから実装する必要はありません（っていうか実装禁止）
・既存のプログラム（ログインなど）を再利用・連携することで、ＣＭＳ１本を作り切るより手間ではありません。
・ユーザープロファイルや管理機能など、自分たちの思うものを開発してリリースすることができます（っていうか実装して）
・フリーのサブシステム（セッション管理、レンダーシステムなど）を再利用することで、フルスクラッチを避けることができます。
・リリースしたＣＭＳが既存の BASE を全否定するものであっても、 XOOPS Cube コミュニティで発表できます。
・XOOPS Cube プロジェクトに持ち込むことで、プロジェクトコミュニティのフィードバックスキーマを利用できます。
・BASE を選択する権利は Module Developer, Expert User, User
にあるため、緊張感を持って開発できます。助言や支援を仰ぐことも容易です。
こんな感じになれば嬉しいと思っています。
コアの提供機能は for Base Developer の部分でしょうか。
整理すると、やはりコアが何らかのユーティリティを実装して提供するというより、
他の人が書いたサブシステムがそのまま使える、というところがメリットになると
思います。
Ogre の場合はファウンダーの Steave がそのサブシステムを大量に書いたので、
全体として Ogre のフィーチャーとしてプッシュできたという感じですね。
--
minahito (mina...@gmail.com)
のぶのぶ
（今までのクローズドMLの習慣で本名で始める習慣が指に残っていて・・・
昨日本名で投げてしまった分、中身無いので・・後でログから削除させてもらいます ＾＾；）
> > いやぁ・・・業界が違うと「機能」という言葉に対してさえも、共通認識がもてないものだとは考えてもいませんでした。
>
> 「伝統的な技術」の定義も早くも怪しいかもしれませんね。(^^;
はい、小生にとっては十分に先進的な異次元の技術かも知れません。
> > ・Base開発者がBase開発する際に XCube Coreをベースにすることによって、
> > 一からスクラッチで開発するときに比べて、どういったメリットが享受できるのか？
> >
> > という点が、もう少しわかりやすくなれば良いだけかもしれません。
>
> ありがとうございます。
>
> では「XOOPS Cube ワールドの特徴（妄想編/目標）」という感じで...
そうそう、こういうのがまずありきだと思うんですよね。
内容の是非は、まだ評価していませんが・・・
現在、ORGEのソースCVSからとってきて、ドキュメントやソースを斜め読みしています。
（ORGEの名前は耳たこ状態で、今更な気もしますが・・・）
おぼろげに判ったことは・・・
確かにエンドユーザ向けには
> コアには「コアからサブシステムに提供する機能は無い」と言わざるを得ません。
> OGRE コア（プラグインを外した部分）には、scene-oriented 能力も 3D 能力もありません。
> ポリゴンの表示すらできなければ、３次元上の計算を行う能力もありません。
なのかもしれませんが、
やはり、ORGEコアをベースｇに開発するプログラマーに対しては
・Scene Management
・ResourceManagement テクスチャーなどの管理？
・Rendering
あくまでも、３Dエンジンオリエンティドな概念からなる枠組みを提供しているわけで・
ただし、中身のロジックは空っぽで、plugin等による拡張部分によって実際の実装がされるので、
minahitoさん的には、「機能」が無いという説明になっていたわけですね。
小生としては、やはり拡張可能な３Dエンジンの中核部分として、拡張を実装する
プログラマに対しての機能提供をしているというおおざっぱな理解ができました。
（中身はさっぱりですが・・・）
今回minahitoさんが書いて下さった内容であれば、小生以外でも何らかのレスなり感想を
フィードバックできるのではと、思いますが・・・・
皆さん、いかがですが？
ところで、
＞ [for Gyouha]
のGyouha って何？？？？
minahito
お疲れ様です。
> 現在、ORGEのソースCVSからとってきて、ドキュメントやソースを斜め読みしています。
> （ORGEの名前は耳たこ状態で、今更な気もしますが・・・）
>
> おぼろげに判ったことは・・・
> 確かにエンドユーザ向けには
> > コアには「コアからサブシステムに提供する機能は無い」と言わざるを得ません。
> > OGRE コア（プラグインを外した部分）には、scene-oriented 能力も 3D 能力もありません。
> > ポリゴンの表示すらできなければ、３次元上の計算を行う能力もありません。
> なのかもしれませんが、
そうですね、エンドユーザー向けというより、サブシステムを開発する側（XCでいうBASE Developer）からすると、コアの恩恵を受けられないという感じです。
OGRE を使ってゲームを書こうとする人から見れば、サブシステムは OGRE の内側に
隠蔽されていますので、「どこまでがコアか？」ということには無関心です。
以下のフィーチャーを提供するモノが OGRE という感じですね。
http://www.ogre3d.org/index.php?option=com_content&task=view&id=13&Itemid=128
> あくまでも、３Dエンジンオリエンティドな概念からなる枠組みを提供しているわけで・
> ただし、中身のロジックは空っぽで、plugin等による拡張部分によって実際の実装がされるので、
> minahitoさん的には、「機能」が無いという説明になっていたわけですね。
はい。 (^^)
実際には XCube_DelegateManager のように、コードが埋まっている種類のサブシステムも
あります。
インターフェイスのみ定義しているサブシステム必須のものと、
標準でもある程度機能するタイプのサブシステム（ただし交換可能）の２種類があるのですが、
ファウンダのSteaveが前者のサブシステムも結構作ったので、このへんの切り分けは OGRE
では問題にならない感じです。
自分で使っていて、気に入らないところがあればサブシステムを書くという感じでサブシステムが
増えていってる感じはあると思います。
Cube の場合は、 BASE の執筆者にご降臨いただかなければならないので、
「BASEからみた Cube の提供機能」
のような視点でコアのメリットを見いださなければならず、苦しいところではあると思うのですが...
> 今回minahitoさんが書いて下さった内容であれば、小生以外でも何らかのレスなり感想を
> フィードバックできるのではと、思いますが・・・・
> 皆さん、いかがですが？
よろしくお願いします m(__)m
> ところで、
> ＞ [for Gyouha]
> のGyouha って何？？？？
ぎょ、業者のつもりでした...ぎょうはに...
--
minahito (mina...@gmail.com)
Tom Hayakawa
ちょっと用語の整理した方がいいかな。
おそらく、この手の話を始めて読む方も多いはず。
少なくとも、XOOPSCubeのレイヤーから見たときの呼び方などはある程度の統一感が無いと、チンプンカンプンじゃないかと思う、今日この
頃・・・。
僕も、そろそろ混乱しそう・・(笑)
コア：
XOOPS Cube 自身の事ですよね。
ＢＡＳＥ：
XOOPS Cube 上に構築されるWebアプリのメインとなるシステム。
Legacy , shade 等と同等機能を提供するシステム。
サブシステム：
僕は、BASEを補うようなライブラリー的なモノを想像してますが、・・・違うのでしょうか？
もしかして、user , render とかも含んだモノをいうのか？そのあたりビミュ～
モジュール：
BASE上に置かれる、実際に表示等を行う部分。legacyのmoduleに相当。（と、僕は理解してるが・・・。）
BASEによっては、add-on , plugin , module などと呼ばれる事もあるでしょうが、
XOOPS Cubeレイヤーから見たときは、モジュールと呼んだ方が判りやすいかな。
すいません、恥を忍んで、僕の理解（解釈）はこの程度です。
「あぁ～勘違い」とかでしたら、ご指摘ください。
> > ところで、
> > ＞ [for Gyouha]
> > のGyouha って何？？？？
>
> ぎょ、業者のつもりでした...ぎょうはに...
うっ・・・・。ググってた・・・・・orz
＃尭葉(Gyouha)とか出てきたので、絶対ガンダーラに関係があると思って・・・・・。
＃おぼろげながらガンダーラが見えたような気がするのは、幻か？蜃気楼か？・・・。
のぶのぶ
On 11月8日, 午前12:21, Tom Hayakawa <Tom.Hayak...@gmail.com> wrote:
> Ｔｏｍです。
>
> ちょっと用語の整理した方がいいかな。
>
実は、小生も同様の事が必要と思って、明日のToDoにしていました。
> コア：
> XOOPS Cube 自身の事ですよね。
異議無し！
> ＢＡＳＥ：
> XOOPS Cube 上に構築されるWebアプリのメインとなるシステム。
> Legacy , shade 等と同等機能を提供するシステム。
この部分は、最終的にはもう少し整理をした方が良いと思います。
> サブシステム：
> 僕は、BASEを補うようなライブラリー的なモノを想像してますが、・・・違うのでしょうか？
> もしかして、user , render とかも含んだモノをいうのか？そのあたりビミュ～
小生も、この「サブシステム」ってのについては、minahitoさんに質問予定でしたが・・・
レンダーサブシステム
認証サブシステム
権限サブシステム
セッションサブシステム
なんてことなんでしょうか？？？？
> モジュール：
> BASE上に置かれる、実際に表示等を行う部分。legacyのmoduleに相当。（と、僕は理解してるが・・・。）
> BASEによっては、add-on , plugin , module などと呼ばれる事もあるでしょうが、
> XOOPS Cubeレイヤーから見たときは、モジュールと呼んだ方が判りやすいかな。
XOOPS Cubeとしてモジュールをどう位置づけるかについても、議論が必要と思います。
・Baseが個別に拡張方法としてのモジュールの実装方法を定義
・XCube自体が汎用的なモジュールの概念を導入して、Baseがその駆動を行う
に、基本的には考え方は分かれると思いますが・・・
たとえば、現状はX2やLegacyを前提にしたアプリケーションモジュール等をモジュールと呼んでいますが・・・
別途、ある別途のルールに則っていれば、ベースを換装してもモジュール自体の動作が可能な取り決めを
XCubeとしておこなうという方向性も考えられるので・・・
（これに似たことはminahitoさんの記事にあったと思うけど・・・）
とりあえず、明日のToDo、50%完です（笑）
> > > ところで、
> > > ＞ [for Gyouha]
> > > のGyouha って何？？？？
>
> > ぎょ、業者のつもりでした...ぎょうはに...
>
> うっ・・・・。ググってた・・・・・orz
> ＃尭葉(Gyouha)とか出てきたので、絶対ガンダーラに関係があると思って・・・・・。
小生も、ググったり、.orgにこういったハンドルのアジア系の人いるのか探したりしてました・・・
では、Good Night！
ITOH Takashi
各論の内容には突っ込めないのですが、まぁざっと感じたところです。
私は他の言語で語れないので、PHP/HTTPだけで語ります。
XOOPSCubeの階層としては、Tomさんの言葉を使うと、
↑上流
モジュール
ＢＡＳＥ ≒ サブシステム
コア(XCLのcoreディレクトリにある23個のファイル)
↓下流
って感じでしょうか。
コアがなすべき仕事って、
・Base間でデータをやりとりしたいときの手順を決める
くらいかと思っています。
このBase間っていうのが
1. 同じサーバ内の同じSystemアカウント（Unixのユーザー）間だったり
2. 同じサーバ内だけど、別のアカウント間だったり
3. XOOPSCubeを使ってるというだけで、サーバは別だったり
でも「最低限のやり取り手順」が決まってるからO.Kっていう。
「あぁ、これXcube使ってるのね。じゃあ＊＊＊＊な手続きで＋＋＋な
情報を得られるんじゃないか」と容易に想像できるという。
ただそれは、ドキュメントでもない限りソースを読む必要があるんじゃないか。
ただ、XCube使ってるんであれば、それなりの手順を踏んでるので、
フックポイントはなんとなく見えるんじゃないかとか。
ただ、PHP/HTTPであることからは逃れられないと解釈してるので、その辺は
3.のケースであれば、RESTでありSOAPなどのAPIであるのかと思っています。
minahitoさんが言っている「CとかJavaが使える」って、あくまでこの
APIをCで叩くっていう意味ですよね？
で、その役割を「Webフレームワーク」っていうかっていうと、
それはSOAPがフレームワークじゃないように違うんじゃないかと思います。
Baseがフレームワークを用意するのはアリというか、大いにそうあるべきと思います。
そういった観点で、23個のファイルについてざっと見ると、
XCube_PageNavigator.class.php
XCube_ActionForm.class.php
XCube_FormFile.class.php
の3つのファイルはなんか、確かに実装により過ぎていて異質な感じはしました。
XCube_ActionFormとか、僕は絶対に使わないし。
あと、次のXOOPS Cubeを考えるのであれば、2008年8月8日で終わるPHP4は
捨ての方向で良いのではないかという気がします。
2年くらい後にはもしかしてPHP5でさえサポートを打ち切られているのかも。
PHP5でinterfaceを使えるだけでもかなり便利なのでは？と妄想します。
（僕使ったこと無いので）
というか、私は感じたこと無いですがPHPだと非力じゃないですか？（苦笑）
あと、私の立ち居地としては、
[Base Developer]
を目指したい
[Expert User]
[Gyouha]
[ModuleDeveloper]
あたりになるかと思います。
# でも、あまりXOOPS案件とかやりたくないなぁ。
# 明らかに、この方向性は仕事での効率と逆方向に行っている・・。
伊藤
gus...@gmail.com
> > ちょっと用語の整理した方がいいかな。
> >
> 実は、小生も同様の事が必要と思って、明日のToDoにしていました。
昨夜、IRCでTOMさんとも話しましたが、私なりの解釈は以下の通りです。
> > コア：
> > XOOPS Cube 自身の事ですよね。
> 異議無し！
これは、私も同じですね。
> > ＢＡＳＥ：
> > XOOPS Cube 上に構築されるWebアプリのメインとなるシステム。
> > Legacy , shade 等と同等機能を提供するシステム。
ここも、TOMさんと大体同じ解釈です。
> > サブシステム：
> > 僕は、BASEを補うようなライブラリー的なモノを想像してますが、・・・違
うのでしょうか？
> > もしかして、user , render とかも含んだモノをいうのか？そのあたりビミ
ュ～
>
> 小生も、この「サブシステム」ってのについては、minahitoさんに質問予定で
したが・・・
>
> レンダーサブシステム
> 認証サブシステム
> 権限サブシステム
> セッションサブシステム
> なんてことなんでしょうか？？？？
この部分、私の解釈としては、単一の機能だけを持ったライブラリに近いと認識
しています。
そういった意味では、のぶのぶさんが書かれているサブシステムなんかは、「機
能」ではあっても「システム」ではなく、あくまで呼び出される側なので、解釈
としては近いかも知れません。
> > モジュール：
> > BASE上に置かれる、実際に表示等を行う部分。legacyのmoduleに相当。（と、
僕は理解してるが・・・。）
> > BASEによっては、add-on , plugin , module などと呼ばれる事もあるでし
ょうが、
> > XOOPS Cubeレイヤーから見たときは、モジュールと呼んだ方が判りやすいか
な。
これも、同じ解釈です。
以上を整理して、伊藤さんが書かれたように階層レベルで整理すると、
----
↑上流
モジュール
BASEモジュール
サブシステム（ライブラリ）
コア（XCを利用する上での基底クラス/サブシステム構築用関数群）
↓下流
----
という認識です。
以下、余談。
> うっ・・・・。ググってた・・・・・orz
> ＃尭葉(Gyouha)とか出てきたので、絶対ガンダーラに関係があると思って・・
・・・。
上記を見て、昨夜TOMさんがガンダーラという単語を出したんですね。
昨夜は、「なんでガンダーラなんだろう？」とあれこれ想像してしまいました^^
;
minahito
おつかれさまです。
全部にレスります、読みづらかったらスミマセン！
用語の整理やりましょう！
＞Ｔｏｍさん
> コア：
> XOOPS Cube 自身の事ですよね。
Yes です。
「サブシステムの定義」（インターフェイスなど）を含みます。
> サブシステム：
> 僕は、BASEを補うようなライブラリー的なモノを想像してますが、・・・違うのでしょうか？
> もしかして、user , render とかも含んだモノをいうのか？そのあたりビミュ～
すみません、これを指すコトバがなくてこないだからついつい使ってしまったのですが、
これは添付画像１を参照してください。
XOOPS Cube は仕事を「なんとかかんとかマネージャー」や、「れがしーこんと
ろーらー」に譲ったり、実装して貰うことで動作します。
従来「交換可能マネージャ」などと呼んでいたものと、コントローラがサブシステムに
なります。
> ＢＡＳＥ：
> XOOPS Cube 上に構築されるWebアプリのメインとなるシステム。
> Legacy , shade 等と同等機能を提供するシステム。
はい。独自のポリシーをもったものですね。
通常、独自に実装したサブシステムを提供し、エントリポイントを持ち、稼働可能です。
データベースアクセスなどを提供するため、実際にはＢＡＳＥが他のモジュールのイン
ストールの認識、（起動のための）積み込み作業を行います。
基本的にはこれを「アプリケーション」と見なして、
さらに追加されるモジュールは「アドオン」と考えるのも手だと思います。
Base モジュールと呼ぶより、 Base アプリケーションと呼ぶべきなのかもしれません。
> モジュール：
> BASE上に置かれる、実際に表示等を行う部分。legacyのmoduleに相当。（と、僕は理解してるが・・・。）
> BASEによっては、add-on , plugin , module などと呼ばれる事もあるでしょうが、
> XOOPS Cubeレイヤーから見たときは、モジュールと呼んだ方が判りやすいかな。
ここがちょっと整理しあぐねているところですが、
XOOPS Cube 上のモジュールとしては、今のところ、
「あってもなくても稼働に支障がなく、外部に直接ＡＰＩを提供せず、 BASE が仲介しない限り働かないもの」
と定義させてください。サブシステムと比較したとき、
・サブシステムは Root に設定、起動方法が規定されている
・モジュールは XCube に実行システムはあるが、その認識や管理は BASE で行う
・サブシステムは型が分かっていればそのまま拡張してよい。 $root->mContext->getLegacyUser() などはＯＫ
・モジュールは API を関数として直接外へ提供してはいけない。デリゲートを使ったイベントによる連携か、仮想サービスの放出のどちらか
・サブシステムの種類と下限上限はコアで決められている（全部のマネージャが必要）
・モジュールはあってもなくても動作には関係ない
という感じです。
--
minahito (mina...@gmail.com)
Tom Hayakawa
minahitoさん、ありがとうございます。
つまり、
-----------------------
- コア(core) = XOOPS Cube
---- + XCube_Root
---- + サブシステム (SubSystem)
-----------------------
であり、「XCube_Root」と「サブシステム」を合わせて「コア（XOOPS Cube）」となるわけですね。
更に、その上層のアプリケーション部が、「ベース(Base)」だと。
で、さて問題の「モジュール」ですが・・・・。
> 「あってもなくても稼働に支障がなく、外部に直接ＡＰＩを提供せず、 BASE が仲介しない限り働かないもの」
> と定義させてください。サブシステムと比較したとき、
>
> ・サブシステムは Root に設定、起動方法が規定されている
> ・モジュールは XCube に実行システムはあるが、その認識や管理は BASE で行う
> ・サブシステムは型が分かっていればそのまま拡張してよい。 $root->mContext->getLegacyUser() などはＯＫ
> ・モジュールは API を関数として直接外へ提供してはいけない。デリゲートを使ったイベントによる連携か、仮想サービスの放出のどちらか
> ・サブシステムの種類と下限上限はコアで決められている（全部のマネージャが必要）
> ・モジュールはあってもなくても動作には関係ない
なんとなくイメージは判ります。
全体における、そのポジションや関わり方は、なんとなくイメージできます。
で、minahitoさん的には、具体的にはどのようなモノを想定してますか？
nobunobuさんが書かれてたような・・・、
> レンダーサブシステム
> 認証サブシステム
> 権限サブシステム
> セッションサブシステム
みたいなモノでしょうか？
minahito
おつかれさまです。
07/11/08 に のぶのぶ<nobu...@nobunobu.com> さんは書きました:
> 小生も、この「サブシステム」ってのについては、minahitoさんに質問予定でしたが・・・
>
> レンダーサブシステム
> 認証サブシステム
> 権限サブシステム
> セッションサブシステム
> なんてことなんでしょうか？？？？
はい、基本的には Root の下にぶらさがり、 Root から Facade 可能なものがサブ
システムという定義でお話しさせて貰っています。
Tomさんへのレスについてた画像にあるものです。
> XOOPS Cubeとしてモジュールをどう位置づけるかについても、議論が必要と思います。
> ・Baseが個別に拡張方法としてのモジュールの実装方法を定義
> ・XCube自体が汎用的なモジュールの概念を導入して、Baseがその駆動を行う
> に、基本的には考え方は分かれると思いますが・・・
> たとえば、現状はX2やLegacyを前提にしたアプリケーションモジュール等をモジュールと呼んでいますが・・・
> 別途、ある別途のルールに則っていれば、ベースを換装してもモジュール自体の動作が可能な取り決めを
> XCubeとしておこなうという方向性も考えられるので・・・
> （これに似たことはminahitoさんの記事にあったと思うけど・・・）
はい、
いろいろ考えているのですが、「モジュール」は「モジューラブル」という概念として
残しておいて、コトバとしては XCube が定義して行くであろう「ジョブ」や「タスク」
といったクラス名を使っていったほうがよいかもしれません。
タスク技法については認識にばらつきがあると思いますので、
こちらをご覧下さい＞ＡＬＬ
アクションフィルターにちょっとだけ似ています。
http://homepage3.nifty.com/moha/prog_task.html
ここでいうＴＣＢの型を XCube が定義することにより、 BASE やモジュールからは
「何らかの方法で自分のＴＣＢをXCubeに預けてしまえばいい」
という考え方が成立します。
その「何らかの方法」（主にインストールと配置）は BASE に依存しますが。
で、このタスク技法の実行メカニズムを今のところ「ランタイムシステム」と仮称し
てます。
で・・・
私的には（おそらく全国的にも）、この「ランタイムシステムを利用したモジューラ
ブル」がガンダーラなのです。
通常、ライブラリは引き込めば使えるため作るほうは楽なのですが、再利用する側から
見ると、走るコードは自分で書かないといけないので、そこまで楽ではありません。
Windows のコンポーネントなどがうまくいっているのは、基本的に奴らはイベントドリ
ブンで「待ち受け」側で、「電話かける」側のプログラムも隠れちゃってるからだと思
います。だから、マウスでドラッグするだけで組み込むことができ、シグナルをつなげ
るだけで、再利用に成功するのではないかと。
奴らは特殊として、
とにかく、使う側からしてみればそのように、「分身の術」とか「ファンネル」みたい
に、スイッチを入れたら勝手に稼働状態に入って働いて欲しいわけです。
それで最近？ちょびっと流行するかもしれないのが、
「スレッドでライブラリを自走させる」
という方法です。
通常、メインループがどのように動くかはアプリケーションによって異なります。
Windowsコンポーネントが再利用に成功しているのはメインループが隠れているからで
す（みんなVisualStudioが吐き出したものや、GUIのフレームワークを使ってそこにルー
プを任せてしまう）
ところが分野によってはここがバラバラなものもある。
そこで誰かが考えた。
「そうだ、スレッドがある。スレッドの使い方はカーネルの下で通常統一されている。
スイッチを入れたらスレッドで勝手に走るようにしよう」
ところがこれが前述のように非常に微妙なのです (-_-;;
が、恐らくこれが「モジューラブル」の現実点だと思います。
アプリのメイン部はそのプロジェクトのチューンや、あるいは社内の伝統的な形で
作り、外から買ったモジュールはスレッドに投げ込んで勝手に仕事させるという...
http://research.cesa.or.jp/pdf/shiryo6-2-3.pdf
の６ページ目左下をご覧下さい。
同じことが書いてあります。
これはマルチコアをどのように使用するかというランタイム・システムで、
それぞれのエンジンで独自にマルチコア制御を持つとのちの再利用が困難になるため、
ランタイム・システムを統一して再利用を促すという考え方のものです。
当然事前処理や事後処理は別途必要ですが、少なくとも稼働までは面倒を見る必要が
無く、モジュールを書く側もメインプログラムを書く感覚で作ることが出来ます。
これがライブラリなら...
この関数はどう呼び出されるか？を考えて書き、大量のＡＰＩドキュメントと呼び出し
手順とセットで提供しなければいけません。特に使うほうは悲惨です。
しかし、モジュールが常に同じ条件下でランするなら、呼び出し待ちのライブラリでは
できないことが再利用可能パーツとして、実現できてしまうのです。
まさに夢の世界ガンダーラ、、、しかし問題も多い！
1) 再利用を提供する側はランタイムシステムに合わせて書かなくてはいけない。
モノによっては楽だが、いちいちやってられないという側面もある。
→モジュールを書く方は苦労する。再利用に価値を見いだして相殺しなければいけない。
2) どうしてもチューニングが甘くなる
それゆえにガンダーラ。。。
理想だけで地に足がついてないからガンダーラ。。。
NEXT XOOPS Cube で書いたのは、
「理想を見て、地に足がついてないのは、根性で、見なかったことにしようぜ」
ということです。
--
minahito (mina...@gmail.com)
Tom Hayakawa
いかん！ボケとった・・・。
> > レンダーサブシステム
> > 認証サブシステム
> > 権限サブシステム
> > セッションサブシステム
>
> みたいなモノでしょうか？
これは、nobunobuさんが、「サブシステム」について言ってた部分だった・・・。
minahito
07/11/08 に ITOH Takashi<tohok...@gmail.com> さんは書きました:
> XOOPSCubeの階層としては、Tomさんの言葉を使うと、
> ↑上流
> モジュール
> ＢＡＳＥ ≒ サブシステム
> コア(XCLのcoreディレクトリにある23個のファイル)
> ↓下流
> って感じでしょうか。
そうですね...どっちが上流でどっちが下流かは、
ふだん上流だの下流だのというコトバを使わないので分からないのですが（またか）
たぶん合ってます。
> コアがなすべき仕事って、
> ・Base間でデータをやりとりしたいときの手順を決める
> くらいかと思っています。
次版でやろうとしているのは、稼働原理（aka ランタイムシステム）部をコアが
直に持とう！というものですが、基本的には、それになります。
（Base間だけでなく、モジュールなどもロジックやレンダリングロジックの使い
回しが効くように）
これをコアが持たないと、 BASE によってレンダーシステムを用いたレンダリン
グの手順が異なってしまうと、再利用が困難になります。またそれは、 BASE が
レンダリングプロセスを実装しなければいけないということにもなります。
それが 11/6 に添付したようなプログラムの書き方をすれば、
コア側がある程度処理もする（処理の固定による制限で再利用が可能になる）けど、
自由度も確保しますよ、というやり方もあります...という話です。
> ただ、PHP/HTTPであることからは逃れられないと解釈してるので、その辺は
> 3.のケースであれば、RESTでありSOAPなどのAPIであるのかと思っています。
> minahitoさんが言っている「CとかJavaが使える」って、あくまでこの
> APIをCで叩くっていう意味ですよね？
あ、いえ、これは、
会社などで CMS を入れる人も多いでしょうから、
「PHP言語ってだけであなたに合いますよ」
っていう意味で ^^
Ruby や Perl の CMS の改造なら本買ってこいの世界でしょうけど、
PHP なら文法がむちゃくちゃ似てるのでほとんどそのままいけますからね。
裏を返せば、引き続き XOOPS Cube を割とかっちり組みますよ～という
宣言みたいなものです。
> そういった観点で、23個のファイルについてざっと見ると、
> XCube_PageNavigator.class.php
> XCube_ActionForm.class.php
> XCube_FormFile.class.php
> の3つのファイルはなんか、確かに実装により過ぎていて異質な感じはしました。
そうなんですよね...
さっきも書きましたが、今はちょっと後悔はしてます。
あえていうなら ActionForm はぎりぎりコアかな（仮想サービスの入力検査機構に
使えそうなので）という感じですが...
> あと、次のXOOPS Cubeを考えるのであれば、2008年8月8日で終わるPHP4は
> 捨ての方向で良いのではないかという気がします。
まぁそうですね、
PHP4/5 で別々に作ってもいいかもしれません。
（とりあえず新作分だけ PHP5）
> PHP5でinterfaceを使えるだけでもかなり便利なのでは？と妄想します。
> （僕使ったこと無いので）
そりゃあ僕としては大歓迎（きっちりやる派）なのですが、
ダックタイピング（そのとき一致すれば動く）言語でインターフェイスってどれく
らいの役割を果たすのか？と真顔で聞かれると正直疑問ではあります。
外部に対して非公開のクラスなら、速度面でそのうちチューニングしないといかん
のじゃないかな...
> というか、私は感じたこと無いですがPHPだと非力じゃないですか？（苦笑）
# 今さら趣味の分野で別の言語に手を出す気がしませんので PHP と心中します (^^;
# その意味でも Cer や Javer は味方に付けた方が良いかと ^^
--
minahito (mina...@gmail.com)
minahito
おつかれさまです。
07/11/08 に gus...@gmail.com<gus...@gmail.com> さんは書きました:
> > レンダーサブシステム
> > 認証サブシステム
> > 権限サブシステム
> > セッションサブシステム
> > なんてことなんでしょうか？？？？
>
> この部分、私の解釈としては、単一の機能だけを持ったライブラリに近いと認識
> しています。
> そういった意味では、のぶのぶさんが書かれているサブシステムなんかは、「機
> 能」ではあっても「システム」ではなく、あくまで呼び出される側なので、解釈
> としては近いかも知れません。
そうですね、Ｔｏｍさんのところで書いて、画像添付しましたが、
モジュール開発者から見て「コア機能に見える」もので、
呼び出される側という見方からは、
搭載を義務づけられたライブラリとも言えると思います。
すみません、
上から順番にレスしたので、下に行くほど（回答済みのため）あっさりですが、
おゆるしください。
--
minahito (mina...@gmail.com)
Tom Hayakawa
いや～、この長文スレを時間があると読み返してるんですが、なぞなぞを解いてるような錯覚に陥ってしまいました。
なんとかイメージを掴んで、簡単な「システム構成図？」（「ガンダーラ想像図（妄想図？）」）みたいなのが作れないかと。
そういうのがあれば、後で、XOOPS Cube のロードマップ的な構想を公開でもした時にでも、イメージしやすいんじゃないかと思うんですよね。
もしかしたら、それでイメージが沸いて、お猿さんや豚さんや河童さんとかが、遥かな旅路を共にすべく名乗り出てくれるのではないかとの、微かな希望を抱
いて・・・(笑)
XOOPS Cube のなぞなぞ。
----------
XOOPS Cube は、「サブシステムの定義」（インターフェイスなど）を含みます。
・Root から Facade 可能なものがサブシステムという定義
----------
・まず、XCubeの核となるRootがある。
・Facedeのパターンを持った有能な美人秘書を配備し、指令を「サブシステム」に渡す。
「サブシステムの定義」（インターフェイスなど）って・・・・、
あっ！もしかして、これって、interface～implements のインターフェイスって事ですか？
ならば、ここで「サブシステム」の型っていうか、そういうのを定義しておくのか。
やっと、なにかキッカケが掴めたような気がする。^^;;
今日のところは、ここまで^^;;
のぶのぶ
> Ｔｏｍです。 （オフトピぎみですが・・・^^;;）
>
> いや～、この長文スレを時間があると読み返してるんですが、なぞなぞを解いてるような錯覚に陥ってしまいました。
小生も、時間を見つけては長文と格闘しています。
で、minahitoさんがreferenceしているページ見たりして謎解きモード突入中で、
なかなか個々のレスでつけられないない状態なのですが・・・
とりあえず、ざっと読んだ上での印象を（これも、少し話がずれていきますが・・・）
やはり、「ゲーム」の世界と「Web」の世界では、同じコンピュータプログラムといっても
まったく異なる世界のものだと感じました。
もっとも大きな違いとしては、「リアルタイム処理及び並列処理の必要性の有無」
というのがあげられると思います。
昔のゲームはともかくとして、今のゲームにはリアルタイム処理は必須です。
で、これを実現するための機能分割というのが自然に必要とされてきています。
たとえば、３Dシェーダーは、PCだとハードのGPU性能で、一つのシーンの
描画の時間は異なってきますが、描画終了を待って次のシーンを決めると
リアルタイム性が損なわれるので、シーンは別途で並列的に計算されていて、
いてどんどんと３Dシェーダー側に投げているのだと思います。
（これは、ゲームプログラムを知らない小生の勝手な憶測です）
もちろんその間の時々刻々のユーザーのコントローラー操作も、ゲーム
プログラム側でこなさなければいけないわけですから、並列処理や、
処理のキューイング、処理の効率化なんてものが必須になってきます。
ところが、WEBの場合には、基本的にはプログラムは一つのリクエストに
対して一つの結果を返せば良い順次処理で、並列的に行う処理の
必要性はかなり低いです。
AJAXが一見そのような仕組みを一部持っているように思われますが、
これは、主にブラウザ側のJavaScriptが行なう処理で、サーバー側の
処理とは完全に切り離されています。AJAXからのサーバへのXML
リクエストは、サーバー側では基本的には順次処理です。
サーバープログラム内で、Webサービスに投げて非同期で結果を取得する
ってなことも最近は増えているので、このあたりは複数サーバによる
並列処理とも考えれられますが。
これは、WEBアプリケーション自体が、基本的には文書の参照ツールで
あったWEBブラウザとWEBサーバという組み合わせで、
まずはサーバー側プログラムが介在したダイナミックな文書生成、
ひいてはユーザーとの対話的なアプリケーションプラットホーム
へと変貌をとげざるを得なかったところに問題があるのですが、
本来はステートレスなリクエストしか受け付けないところに一定の
パラメータを付与することによって一連の対話の連続性を持たせる
セッションという概念を持ち込んだりしなければならないのも、
この本来の目的外での使用である事が発端となっています。
この違いは、コア部分を設計する上でかなり重要では無いかと思います。
つまり、ゲームの世界では、ゲームが動いている限りそのプロセスは
動いていて、リクエストはそのプログラムが受ける。
なので、コアやBaseの作りが複雑でもロードされるのは一回で、
きっちりとそのフレームがロードされれば、一つの空間のなかで
イベントに対応した処理が動かせる。（こんなに単純では無いと思いますけど）
ところが、WEBのプログラムでは、コアやベースという様に呼べども、
結局は、HTTPリクエストごとに別のプロセスとしてロードしなければならない
ので、構造を集約化してきれいにすればするほど、オーバーヘッドが
大きくなる。
（簡単な例で言えば、フロントコントローラで処理の集約をすることによって
ページコントローラに比べて処理を切り分ける分オーバーヘッドがあるって
な事です）
開発の立場からすると、きっちりとした構造で書けるということは、品質面から
考えてもとても大切なので、これを否定するわけではありませんが、
こんかい、一連の書き込みを読みながら、とりあえず感じたことは、
あくまでも、基本はステートレスな逐次処理であるという前提のなかで、
オーバースペックにならないような工夫が必要ではと感じたしだいです。
まだまだ、消化不良なので、いささか尻つぼみ（支離滅裂）レスですが。
とりあえず、スレ放置しているのではないという連絡の為に書きました。＾＾；
で、今回はこれまで。
minahito
おつかれさまです。
僕がタスク技法を導入することに踏み切った理由のひとつに、
「Ｗｅｂは逐次処理である」
ということがあります。そして、ＸＯＯＰＳは、
「ユーザーがインストールしたモジュールで逐次処理の内容が変わる」
アプリケーションです。
逐次＋モジューラブル＝タスク技法だ！！
ということで、僕は僕なりに Web が「結局、逐次処理である」ということ
を踏まえてフォーラムにカキコミをしました。
（実際「Web だろうとなんだろうとシーケンシャル処理」という発言は、
元のフォーラムのカキコミにも入っていたと思います）
ということで、これ自体は２０年くらい前、マシン語プログラムからある
技法なので、見たことがあるという人も多いと思います。
が共通認識を持つために（また見たことがある、という人には、思い出し
ていただくために）、改めて説明します。
こちらの業界での歴史を書くと、前にもリンクを置きましたが:
http://homepage3.nifty.com/moha/prog_task.html
http://homepage3.nifty.com/moha/programming.html
1981年「ボスコニアン」で初めてビデオゲームにこの手法が導入され、
ライバル会社の技術を盗むための基盤の逆解析（当時は常識だった）によっ
てゲーム業界全般に広まり、さらにそれが後輩に伝えられ→転職し→...
の流れの中で15年後にはすでに雑誌や入門書で紹介されるほど一般化され
たという技術です。元は当時のＯＳの制御システムの応用です。
これが２６年の時を越えて現在まで生き残っている理由のひとつに、この
技術が当時はアセンブリで書かれていたとはいえ、考え方としてオブジェ
クト指向技術だから、ということが挙げられます。
現在ではＣ++とオーバーライドを使って書くのですが、基礎理論は変わり
ません。
ＴＣＢというインスタンスに、コールバックという仮想関数を持ち、ジャ
ンプアドレスを書き換えて Change State し、キルタスクでデストラクタし
ていたという感じです。
これは数キロバイトのメモリと数ヘルツのＣＰＵの資産をいかに逐次処理で
引っ張り出し、かつモジュール設計にして生産性を高めるか？という技術で
す。最大のポイントは２６年前に既にコントローラとモジュールの分離を実
現していたことにあります。
[添付画像 Fig1]
タスク技法の基本は、ＴＣＢ（タスクコントロールブロック）という、
・データ
・ロジックを呼ぶためのアドレス
・次のＴＣＢへのポインタ
から構成されるリスト構造です。
Cube ではアクションフィルタが近いと思いますが、このＴＣＢのリストを
構築し、先頭から順次ロジックを呼び出すことで、処理を行います。
[添付画像 Fig2]
タスク技法がアクションフィルターなどのイテレーション処理ともっとも
異なるのは、「タスクがタスクを生成できる」点です。
アクションフィルターは XOOPS Cube が直接リストの作成に関わっていま
した。
タスク技法の場合は、親となるタスクをリストに組み入れれば、親が必要な
タスクをリストに追加して処理を行います。
これは、コントローラがタスクリストの実行に対して責任を負うが、最初に
作ったタスク以外のタスクの生成のロジックを積まなくてもコントローラが
成立することを意味しています。
XOOPS Cube に置き換えれば、
1. Base に対するモジュールがどう配置され、どう現在のＵＲＬに有効なのか
は Base しか知り得ない
2. しかしモジュールはコードの再利用を促進するため、実行部を TCB で書い
ておけば応用が利くことになる
ということになります。
つまり、サイト１アクセスに必要な逐次処理ブロック（ブロック、モジュール
など）のリストアップを site_xxxx.ini.php から特定可能な Base の初期タスク
に任せてしまうのです。
しかし Base 下のモジュール（アドオン）を書くプログラマは、実行理論は、
Cube コアのコントローラの統一理論に委ねることができます。
言い方を変えれば今後のモジュールの開発の理想型は、統一コントロールに
供給する部分と、それを Base に認識して貰うための部分を分けるというこ
とです。
たとえば C# 等では foreach () 中にリストを書き換える挙動を行うと、エラー
になります（確かコンパイルエラーだったような...）
foreach ($tcb in $tcbList) {
$tcb->do(); // この中で $tcbList に要素を追加するとエラーになる
}
[添付画像 Fig3]
Ｗｅｂには関係ありませんが、ＴＣＢは次の処理を生成し、自分のＴＣＢを
殺すことによって、処理をどんどん切り替えることが可能です。
この Fig3 画像はゲームを例に取ったものですが、初期化画面タスクが、タイ
トル画面タスクを生成せず１面準備タスクを実行するようにちょこっと弄る
だけで、実行時にいきなりゲームが始まるなど、開発の状況や没案などに合
わせて自由にプログラムの処理状況を弄れたわけです。
完成していない部分をスキップしたり、完成した部分を後から付け足したり、
挿入したりということも「自由自在」。それこそ感覚的には、ＦＦＸＩＩの
ガンビットをいじるようにやっていたわけです。
[添付画像 Fig4]
さらに自分が就職した頃にはメインメモリも１メガほどありましたから、か
なり余裕があり、開発中であれば、タイトル案Ａタスクとタイトル案Ｂタス
クをプログラムしておき、アセンブラにかけるときに切り替えて、２案を見
せて作り込んでいくことも出来ました。
もちろんタイトルＡがタイトルＢを生成することで、タイトルの後タイトル
が出る、という特殊な処理にすることも可能です。
まさにモジュールです。
[添付画像 Fig5]
ここまでは画面遷移的に書きましたが、実際には「画面遷移後の初期化を行
うタスク」をコールして、それが初期化処理と同時に必要なタスクを生成し、
キルタスクすることでプログラムが進行していました。
もちろん進行中も必要に応じてタスクが自分で判断してタスクの追加や自殺
を行います。
右の図の場合、「輝くロゴ」と「揺れるロゴ」の２種類くらい作っておいて、
差し替えることで色々試してみることができます。
--------
ちなみに僕がＣ＋＋のオブジェクト指向技術が理解できなかったのは、それ
がＴＣＢの技法と何が違うか分からなかったのです。
オブジェクト指向技術は次世代の技術だと思っていたので、なぜフルアセン
ブリでシコシコやってた時代の技術とイメージがかぶるのか理解できなかっ
た。
苦悩して uno さんに相談したとき、「ＴＣＢはあれはあの時代のオブジェク
ト指向技術だ」とアドバイスしてくれて、やっとＣ＋＋を使っていける足が
かりを得たのです。（ちょっといい話）
--------
僕が XOOPS Cube に持たせようとしているのはＴＣＢにあたるクラス
（現代プログラミングでは、 XCube_ActionFilter のようなものになるだろう）
と、そのリストに実行処理をかける部分です。
今風に言えば生成と実行を分離するという言い方になるかも知れません。
Cube は実行部、 Base は生成部です。
Cube コアからみれば「一番最初のタスク」が呼び出せればいいわけです。
それはコンフィグから特定できます。一番最初のタスクは URL を解析して
処理に関与するＸ２でいうところの「ブロックとモジュール」を特定して
タスクを自分の次へ次へとどんどん追加する。
つまり「逐次処理を作成しながら逐次処理していく」のです。
もちろんブロックとモジュールにもタスクを追加する権利があります。
あとはレンダーターゲットという考え方を適用して、タスクが描画できる
範囲を最後に合成する。
すべてのプログラムはタスクにロジックを書き、レンダーターゲットに出
力しているに過ぎませんが、それが合成されて、出力後の人間の目には、
「ブロック」とか「モジュール」に見えるという理屈です。
これは単に巨大な絵をパネル事に分割してそれぞれのタスクに作画して貰
うと考えていただければＯＫです。どう分割するか、どのタスクにパネル
を委ねるかはユーザーが設定画面でモジュールを配置して決めることです。
ただCubeがパネルを定義することで、各タスクはBASEごとに「パネルの
形が違うんじゃないか？」と心配する必要が無くなります。
（さらにユーザーレベルでレンダーシステムを偽造することでさらに、
組み合わせの可能性が広がる。プログラム側は単にストリクトに書けばＯＫ）
逐次処理をプログラムに直書きすれば、それは「ハードコードされた逐次
処理」になります。
タスク技法で書けば、「各タスク（それすなわちユーザーの設定の反映）が
"動的に構築する"逐次処理」になります。
Web サービスの利用側も、フォーク/ジョイン（外部の処理が終わるまで待つ）
を行う一種のタスクと言うことになります。
・・・という感じなんですが、伝わりましたでしょうか？
--
minahito (mina...@gmail.com)
minahito
あ、あれ！？ 昨日２時間かけて書いた 0:49 のレスが配信されていない... orz
gus...@gmail.com
> あ、あれ！？ 昨日２時間かけて書いた 0:49 のレスが配信されていない...
orz
どうも、配信遅延が起きてたっぽいですね。
Gmail以外のアカウントにはもっと早めに来ていたので、Gmail限定かも^^;
minahito
のぶのぶ
これも、言葉(用語)に対する、受け取り方の問題なのかぁ・・・・
小生にとっては、「タスク」とか「TCB」とかは、マルチタスクOSや
リアルタイムOSのカーネルに関連する用語って意識が強く、
・「タスク」＝ マルチタスクの処理単位
・「TCB」＝OSのタスクディスパッチ管理用のテーブル構造
という認識がありました・・・
が・・・・
おそらく、minahitoさんが意図されているのは、
WEBが逐次処理であるということを前提にして、その逐次処理の中で
実行されるべきファンクションやその処理順序を、TCBに似たのような
ファンクションポインタを持った双方向リンクリストを基ににして駆動する
ようにしたい。
よって、
「タスク」＝ 特定の目的を問わない処理の単位
（何をするかは、呼ばれた側だけが知っている）
「TCB」 ＝ 各処理へのファンクションポインタを持った双方向リスト
（ファンクションポインター配列に比べて、
処理順などのメンテナンスが簡単にするため）
ってことなんだ、と理解しましたが・・・
さて、何点もらえるかなぁ＾＾；
minahito
お疲れ様です。
> ところが、WEBのプログラムでは、コアやベースという様に呼べども、
> 結局は、HTTPリクエストごとに別のプロセスとしてロードしなければならない
> ので、構造を集約化してきれいにすればするほど、オーバーヘッドが
> 大きくなる。
> （簡単な例で言えば、フロントコントローラで処理の集約をすることによって
> ページコントローラに比べて処理を切り分ける分オーバーヘッドがあるって
> な事です）
タスクを使うにせよ、
Cube の場合、サブシステムだけは全ロードせざるを得ませんよね...
タスクのほうは、リストに繋がないものは読み込む必要がないので、それを
使うことでリクエスト事にロードし、メモリアロケーションする量を適宜減らす
ことができると思います。
タスクリストの概念図を送りましたが、
最初のタスクを生成するときに状況に応じて「最初のタスクに何を送るか」を
切り替えることができますし、その最初のタスクが処理に応じて軽めも重め
も自由自在にできるのではないかと思います。
（たとえばダイナミックＣＳＳ処理を申請されているなら、リストにつないでいく
タスクも限定できる）
処理をタスクにすべて持っていけば、状況に応じてリストにつなぐ、つながな
いを選択していくことでロード負荷と処理負荷を低減し、徹底的にチューニン
グできます。
（なにしろもともとは８ビットＣＰＵ、1kバイト未満のメインメモリの性能で、メモ
リをどう割り当て(*)、どうCPUのパワーを引き出すか、という観点で使われてき
た貧民技術ですから）
ただし、これだとプログラムする負荷が高まりますので、常時読み込まれ、交
換が容易なサブシステムというのはタスクというランタイムメカニズムとは別途
持つべきだと思います。
(*)TCBを64バイトと決めたら、あとはTCBの最大値を32まで、と決めることで
最初から２キロバイトを割り当てておくことができる。
それで使用中リストと、未使用リストを組んでおけば、２キロバイトの中で作成、
破棄を回すことができる。
ここをクラスドリブン、オブジェクト解釈ではなく、配列を使ったマジTCB再現に
すれば無茶苦茶速くなると思います。 (^^;
$tcb[$i]['func'] = "関数名"; //< ここを書き換えて再利用する
ただいずれにせよ、最終的なアプリケーション処理内容はユーザーの手元で
決定しますので、自動チューニングにはある程度限界はあると思います。
--
minahito (mina...@gmail.com)
のぶのぶ
> 「TCB」 ＝ 各処理へのファンクションポインタを持った双方向リスト
> （ファンクションポインター配列に比べて、
> 処理順などのメンテナンスが簡単にするため）
って書きましたが、確かに
07/11/16 に minahito<mina...@gmail.com> さんは書きました:
> 配列を使ったマジTCB再現にすれば・・・
ってあるように、
マルチタスクのTCBの用に頻繁なタスクの消滅や優先順位の変更などの
メンテナンスは必要ないので、双方向リストである必然は無いですね。
minahito
とりあえずイメージだけでも伝わるように、例によって「動かない」コードを書きま
した（書き足しました）。電車の中で書いたやつです。
> これも、言葉(用語)に対する、受け取り方の問題なのかぁ・・・・
>
> 小生にとっては、「タスク」とか「TCB」とかは、マルチタスクOSや
> リアルタイムOSのカーネルに関連する用語って意識が強く、
>
> ・「タスク」＝ マルチタスクの処理単位
> ・「TCB」＝OSのタスクディスパッチ管理用のテーブル構造
>
> という認識がありました・・・
これはほぼ完全に同じ感じでイメージできていると思います。
元々タスク技法がそっちの出身ですから、違ってないはずだと思いました。
言葉の定義も nobunobu さんのが正しいと思います。
ただ僕の場合、 TCB に必要な情報が収まった状態（というか現代プログラムでいえば
抽象クラス XCube_Task を拡張し、実装したサブクラスのインスタンス）を「タスク」
と呼んでいました。
> おそらく、minahitoさんが意図されているのは、
> WEBが逐次処理であるということを前提にして、その逐次処理の中で
> 実行されるべきファンクションやその処理順序を、TCBに似たのような
> ファンクションポインタを持った双方向リンクリストを基ににして駆動する
> ようにしたい。
>
> よって、
> 「タスク」＝ 特定の目的を問わない処理の単位
> （何をするかは、呼ばれた側だけが知っている）
>
> 「TCB」 ＝ 各処理へのファンクションポインタを持った双方向リスト
> （ファンクションポインター配列に比べて、
> 処理順などのメンテナンスが簡単にするため）
はい、 TCB という単語を引っ張り出したのは共通認識を作るためで、
基本は「ＴＣＢの似たような」「タスク」ってことでバッチリです (^^)
# 現代のタスク技法はそういうやり方になってます。
# 添付の XCube_Task みたいにかつてＴＣＢに必要だったプロパティ＋純粋仮想関数
# を拡張してタスクを実装する、という感じです。
単語として TCB を引っ張り出したのは、一旦話を原始に戻したかったからです。
恐らく実装時はルックアップテーブルとしてのTCBと、処理を分けずに、直にやることに
なると思います。
（重いかも知れないが）
ただもし超高速にやる必要があるなら、 PHP のメモリ割り当てがどうなっているのか
分かりませんが、最初に必要なデータだけをおさえられるルックアップ用の（ＴＣＢ）
固定バッファを用意して、そのなかでやりくりするという方法も考えられます。
ルックアップテーブルとしてのＴＣＢリストだけシリアライズして保存することで
キャッシュにできるかもしれませんし...
> さて、何点もらえるかなぁ＾＾；
ひいっ (^^;;
おそれおおいっ
> > 配列を使ったマジTCB再現にすれば・・・
> ってあるように、
> マルチタスクのTCBの用に頻繁なタスクの消滅や優先順位の変更などの
> メンテナンスは必要ないので、双方向リストである必然は無いですね。
そうですね。
ただ・・・添付のものは一応双方向にしてキルタスクも実装しています。
使う場面がぜんぜん想像つきませんけど（爆）
あと、 BASE 側で先頭処理と後方処理の２つぶんのタスクを積むことを
想定して、
function &createRootTask()
{
$task1 =& new BASE_BeginTask();
$task2 =& new BASE_EndTask(); // ケツのdrawでテーマを処理しないとまずい
$task1->addTask($task2);
....
return $task1;
}
タスクに優先度はないが、子供は持てるようにしています。
子供は子供で兄弟を持てますので、世代はいかないと思いますが、ツリー状になります。
いま
- 開始処理専用タスク
- 終了処理専用タスク（テーマの描画）
だとすると、ブロックやモジュールなど、テーマより先に描画が終わっていないと
いけないタスクは
- 開始処理専用タスク
-- ブロック１
-- モジュール１
-- ブロック２
- 終了処理専用タスク（テーマの描画）
という具合にルートタスクの子としてぶら下げます。
これで数値による優先度制御ではなく、生成時固定の相対的な最低限の処理順制御
が可能です。
タスクの巡回は、
for ($pTask =& $rootTask; $pTask != null; $pTask =& $pTask->getNextTask());
みたいなのでいけるようになっています。
ツリーの総当たりと同じやり方です。
# タスクは子（長男）がいれば子を次の処理順のタスク
# 弟がいれば弟を次の処理順のタスクとして返す。
# 弟がいなければ、親の弟を捜す（弟がいる世代まで幹をさかのぼる）。
minahito
サンプルはだいぶ間違ってました。
いま手元である程度修正してサンプルをのせているので、
sf.net forum にある「ＣＶＳの名前どうする？」っていうのに答えが出たら（出したら）
コミットします。
Task Control System を導入する意味について、
その元となっているイメージ....ランタイムシステムの実行体をモジュールが持ち、放流
してもらうだけで稼働状態で組み込まれる...の話をスライドにまとめました。
対話型クイックタイムになっていますので、マウスを押して進めてください。
ダウンロード推奨です！
http://homepage.mac.com/minahito/.Public/Gandhara.mov
説明用にさくっと作るはずが途中から...
--
minahito (mina...@gmail.com)
のぶのぶ
> ダウンロード推奨です！
これって、一旦ダウンロードしてから見ること推奨って事だったんですね。
「推奨」＝「見ろ」って受け取って、速攻でクリックしたんですが、
コンテンツよりも、写真が頭に焼き付かれてしまいました＾＾；
（ガンダ～ラ、ガンダ～ラ ゼイ セイ イット イン イ～ンディア）
今晩は、少々酔っぱらっています
minahito
ぐちゃぐちゃのままですが、サンプルコード投げます。
レンダリングシークエンスのところは、レンダラブルなものを収集する過程に関しては
変更予定ですが、タスク技法のところはおおむねこのイメージです。
ルートが一度なにもしないタスクを作り、
ベースにそれを投げるのでベースがそこに自分のタスクを繋げる。
さらにそのタスクの初期化時にモジュールやブロックに相当するタスクを繋げていく
イメージです。
このタスクをどうベースが生成するかがベースのスペックですけども、
キューブから見たときにその取り扱いは関係なくなります。
--
minahito (mina...@gmail.com)
minahito
調整版をプロジェクトのフォーラムに投稿したのでこちらにも貼っておきます。
http://sourceforge.net/forum/message.php?msg_id=4653104
--
minahito (mina...@gmail.com)
minahito
ロードマップどおり！？１２月８日付けでスナップショットを出しました。
詳細はこちらをどうぞ。
http://sunday-lab-ja.blogspot.com/2007/12/snapshot-of-next-xoops-cube-released.html
まぁ、というところです。
ドキュメントがデカイせいか現時点で各 sf のミラーに行き渡っていないという情報もあります。
でもぼちぼち落とせるようになると思います。
minahito
あけましておめでとうございます。
タスク技法について、よりまとめているページがあったのでご紹介します。
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html
あと上のページからリンクされているページですが、White Paperというページなどでもきれいにまとめられています。
http://homepage3.nifty.com/moha/prog_realtime.html
（続きもよんでね）
特にこれ
http://homepage3.nifty.com/moha/prog_object.html
> http://www.antun.net/tips/howto/task.html
「ゲーム業界独自の技術」とありますが、前に書いた通り、これは元々はジョブコンの応用だったらしいという話を、
昔、先輩から聞いたことがあります。描画まわりのところが面白いです。
> タスクシステム自体に描画機能が入っていようとなかろうと、 描画と計算処理は別々の関数で行うことが普通です。
> 一通りのタスクの計算処理が行われた後に、それぞれの描画関数が呼ばれます。 この時、計算処理は計算処理で、
> 描画は描画で、優先順位を持って その順番で処理されていくことが多いです。
ここにあるように、ゲーム専用機は描画を直接ハードウェアを叩いて行いますので必然的に処理と描画は分かれます。
XOOPS Cube もそうなっています。ここでいう「優先順位」がレンダーシークエンスのレイヤープライオリティです。
僕がXOOPSを通じてビジネスアプリの本を読み始めた頃、本に「処理と描画を分けて……」という話が書いてあって、
意味が分からなかったことがありました。
あっちの業界ではそれをCとVの分離だとかMCとVの分離だとかいうらしいのですが……
こっちはハードウェアが描画を開始する時分に割り込んだり、待ったりしてから描画に入るので、
処理と描画はハードウェアの必然上分離しますが、MVCは用語自体存在しません。
ただこれは非常に制御がしやすい技法で、
しかも何となくMVCに見えるし、まったく知らない人には新鮮に見えるだろうし、特にXCの目的に挑むにはこの方法が
ベストだと思います。
たぶんnobunobuさんが綺麗に解説してくれると思います（すごい振り）
minahito
> ここにあるように、ゲーム専用機は描画を直接ハードウェアを叩いて行いますので必然的に処理と描画は分かれます。
に興味のある方は
http://homepage3.nifty.com/moha/prog_tv.html
に話があります。
だからVを分離するって話、よく分からないんです。(--;
「Vを分離しない」ってどういうプログラムなのかが分からない。
余談ついでに誰か教えてください (^^;
minahito
昨年１２月８日のスナップショットと一緒に出したドキュメントの修正を考えています。
実はこのドキュメント、デタラメ英語側は結構質問とか（英語がでたらめだったからでしょう
けど……）、メールがきて、スライド共有サイトにアップしてもらったりして、反応があった
のですが、
日 本 で は レ ス ポ ン ス ゼ ロ で し た orz
ということで、次のドキュメントはもっと分かりやすいものにしたいのですが、
具体的にここが分からなかった！とか、ここをこうすればよくなる！
といった要改修点というか、
読書感想を切望してます (^^;;;
ぜひ忌憚ないご意見をお聞かせください。
関連ドキュメントとして
http://sunday-lab-ja.blogspot.com/2008/03/diff-between-xc-and-xclx2-render.html
や
http://xoopscube.org/modules/news/index.php/node/81?
（こっちはムービー）
があります。
--
minahito (mina...@gmail.com)
K. Ono
海外のMLとかだと何らかの反応ありますが、確かに何もないですね。。
僕もコードをそれほど詳しく見ていなかったので^^;
これを機会に少し詳しく見させていただきました。
コード的な流れだと下記のようになっていますね
1. $rootTaskを頂点とするtaskのCompositeをControllerがビルドする。各taskはそれがdrawableの場合にRenderOperationを有する。
2. taskのCompositeをRenderCollectorがVisitしてtaskのCompositeからRenderOperationを抽出してRenderOperation
のCompositeを作る。この時点でRenderOperationがSequence IDおよびRenderSystem名でソートされる
3. RenderOperationのCompositeをRenderableがVisitして各RenderOperationの内容からRenderTargetを作り、RenderSystemが
RenderTargetをrenderする。
4. RenderTargetのrender結果を出力
Composite/Visitorパターンの理解が前提ですが、それさえ理解できていれば特に分かりにくくはないと思います。
ただ、コードを詳しく見て少し分かりにくいと思った点はXCube_Root::execute()の部分です。
$collector =& new XCube_RenderOpCollection();
$rootTask->acceptCollectorAll($collector);
$visitor =& new XCube_RenderableVisitor();
$collector->acceptVisitor($visitor);
これは好みの問題なのかもしれませんが、外から使う側としてはVisitorの部分が見えていない方が
分かり易いのではないかと。。acceptXXX()とかでVisitorパターンを実現する部分に関してはVisitorパターンの
当事者（Visitする側とVisitされる側）のみが考えるだけで、外には出さない方が分かり易いかな？と思います。
また、XCube_RenderableVisitorとXCube_RenderTargetは統一してしまうこともできるのではと思いました。
下記はあくまでもリファクタリング案ですが、
class XCube_Root
{
...
function execute()
{
$this->initialize();
$dmy = null;
$rootTask =& new XCube_Task("root", $dmy);
$this->mController->buildTask($rootTask);
$rootTask->initializeAll();
$rootTask->updateAll();
$render_operations =& $rootTask->drawAll();
print $this->$mRenderTargetScreen->render($render_operations);
}
class XCube_RenderOperationCollection
{
var $_operations = array();
function addOperation(/*XCube_RenderOperation*/ &$operation)
{
$this->_operations[$operation->mSequenceId][$operation->mRenderSystemName][]
=& $operation;
}
function acceptRenderable(/*XCube_Renderable*/ &$renderable)
{
ksort($this->_operations); // sort
foreach (array_keys($this->_operations) as $key) {
foreach (array_keys($this->_operations[$key]) as $key2) {
foreach (array_keys($this->_operations[$key][$key2]) as $key3) {
$renderable->visitRenderOperation($this->_operations[$key][$key2][$key3]);
}
}
}
}
}
/*
interface Xcube_Renderable
{
function render(XCube_RenderOperationCollection $operations){}
}
*/
class XCube_RenderTarget /*implements Xcube_Renderable*/
{
...
function render(/*XCube_RenderOperationCollection*/ &$operations)
{
$operations->acceptRenderable($this);
}
function visitRenderOperation(/*XCube_RenderOperation*/ &$operation)
{
$this->reset();
$this->setTemplateName($operation->mResourceName);
$this->setAttributes($operation->mAttributes);
$this->setAttribute('bufferMap', $this->_mBufferMap);
$this->setAttribute('tagMap', $this->_mTagMap);
$root =& XCube_Root::getSingleton();
$render_system =& $root->getRenderSystem($operation->mRenderSystemName);
$render_system->render($this);
$this->_mBufferMap[$operation->mSequenceId][] = $this->getResult();
if (isset($operation->mTag)) {
$this->_mTagMap[$operation->mTag] = $target->getResult();
}
}
}
なお、XCube_RenderOperation::mLinkedRenderTargetというのものがありましたが、どういった状況の場合に
これがあるのか不明でしたので、上では使っていません。
ただ、ここまで書いて思ったのは、RenderOperationとRenderTagetの役割の明確な違いが見えないことです。
ほぼ同一の役割のようにも見えるので、その場合はこれら２つのクラスも統一することで更にリファクタリングができ
そうです。
K. Ono
コード部分にちょっとタイポありましたので、再送します。
class XCube_Root
{
...
class XCube_RenderTarget /*implements Xcube_Renderable*/
{
...
$this->_mTagMap[$operation->mTag] = $this->getResult();
}
}
}
K. Ono
ちょっと抜けているところがあったようですので、更に追加します。
あくまでも案なので、どんどん投稿させていただきます^^;
なお、コメント化している部分はPHP4のためです。
class XCube_Root
{
...
class XCube_RenderTarget /*implements Xcube_Renderable*/
{
...
return $this->getResult();
}
function visitRenderOperation(/*XCube_RenderOperation*/ &$operation)
{
$this->reset();
$this->setTemplateName($operation->mResourceName);
$this->setAttributes($operation->mAttributes);
$this->setAttribute('bufferMap', $this->_mBufferMap);
$this->setAttribute('tagMap', $this->_mTagMap);
$root =& XCube_Root::getSingleton();
$render_system =& $root->getRenderSystem($operation->mRenderSystemName);
$render_system->render($this);
$this->_mBufferMap[$operation->mSequenceId][] = $this->getResult();
if (isset($operation->mTag)) {
$this->_mTagMap[$operation->mTag] = $this->getResult();
}
}
}
class XCube_Task
{
...
function &drawAll()
{
$collection =& new XCube_RenderOperationCollection();
for ($pTask =& $this; $pTask != null; $pTask =& $pTask->getNextTask()) {
$pTask->draw($collection);
}
return $collection;
}
}
/*
interface XCube_Drawable
{
function draw(XCube_RenderOperationCollection $collection);
}
*/
minahito
お疲れさまです。
onokazuさんありがとうございます！
> これは好みの問題なのかもしれませんが、外から使う側としてはVisitorの部分が見えていない方が
> 分かり易いのではないかと。。acceptXXX()とかでVisitorパターンを実現する部分に関してはVisitorパターンの
> 当事者（Visitする側とVisitされる側）のみが考えるだけで、外には出さない方が分かり易いかな？と思います。
この機構ですが、PDFの50ページ、52ページにあるように、
タスクからレンダーオペレーションを改修する部分は共通（つまり final）にして、かつ、
開発者の拡張を確保するために、 Visitor を交換可能にする予定でそうしました。
この部分の拡張は少し特殊で site_config.ini.php で設定できる拡張部ではない予定で考えています。
コレクターを交換可能にするとタスクとコレクターの通信部に亜流が許されるため、あくまで
収集は XCube の固定的な方法で行って、収集したものを「どう使うか？」の部分をコアとは違う
$visitor を用いる事で修正可能という方針にしてあります。
（まぁこの機構も含めて OGRE からそのまま持ってきた処理ポリシーです^^）
個人的にはこの部分の交換を使用するのは、
汎用レンダーシーケンスの手順ではどうしても仕様を満たせない独自カスタマイズのサイトだろう、
というイメージを持っています。
このあたりはいらねーぞ！ということになってくれば（なりそうだ）
onokazu さんの整理案でいってみようと思います。
> ただ、ここまで書いて思ったのは、RenderOperationとRenderTagetの役割の明確な違いが見えないことです。
> ほぼ同一の役割のようにも見えるので、その場合はこれら２つのクラスも統一することで更にリファクタリングができ
> そうです。
うぉ、実はそのとおりです。
# むちゃくちゃ鋭い指摘です
いや、あの、レンダーターゲットはレンダーバッファの抽象化なので、統一してどっちか消す、
というのはやりたくないのですが、
今のレンダーターゲットが「これレンダーオペレーションでは？」というメンバを積みまくっている
のはご指摘の通りです。
XOOPS Cube コア 0.9 にはレンダーオペレーションという考え方をまだこちらに持ってきていなかっ
たので、
・描画が使用するリソース名:テンプレート setTemplate
・描画に関わるパラメータ:アトリビュート setAttribute
などをターゲットにセットすることになっています。
しかし、これ実は元モデル（パクリ元）から見てもおかしいのです。
XOOPS Cube はモジュールが入れ替え式・追加可能であることに描画レベルで対応するために、
基本的にビデオ描画出力を出力モデルに取り入れている事はご存知かと思います。
（といっても基本的な考え方は文字出力と変わらない）
本来、出力時に変動するパラメータや、出力対象となるバッファ（＝レンダーターゲット）は、
レンダーシステム側に設定されます。
$renderSystem->setRenderTarget($target);
$renderSystem->setTemplateName(..); // ←これはないけど
$renderSystem->setAttribute(xxx, xxx);
$renderSystem->setAttribute(xxx, xxx);
$renderSystem->setAttribute(xxx, xxx);
$renderSystem->render();
普通のレンダリングエンジンは、これの直書きを防ぐために、描画命令という概念を持って
います。
"レンダーオペレーション" をバッチの１命令みたいな感じで発行し、
レンダーシーケンス側でそれを読み取りながら、描画段階で設定と描画を繰り返すことで
描画を行います。
ところが、 XOOPS Cube 0.9 の場合、「レンダーシステムにどうパラメータを設定するか」
ということを、ターゲットに設定していました！
$renderTarget->setTemplateName(..);
$renderTarget->setAttribute(xxx, xxx);
$renderTarget->setAttribute(xxx, xxx);
$renderTarget->setAttribute(xxx, xxx);
$renderSystem->render($renderTarget);
いろいろ 0.9 設計上（対 Legacy）の理由はあるのですが、色々考えていただくより、
「レンダーターゲットとレンダーオペレーションがごっちゃになっているから
修正すべき対象」
と考えてください。
1.0 はこの 0.9 のメンバを残したため、新たにレンダーオペレーションという概念を追加した
1.0 では、汎用レンダーシーケンス上で、レンダーオペレーションとレンダーターゲットの
役割分担が不明瞭になります。
onokazu さんの指摘は非常に正確なものです。
統一がよくないというのは、
実際には、レンダーターゲット（レンダーバッファ）はレンダリングを受け取るバッファを
抽象化したものなので、
$renderSystem->setRenderTarget($renderTarget);
$renderSystem->render();
のように、「レンダーオペレーションなしでも、描画可能」というレンダーシステムの
独立性を成立させるために、（今の形とは違うものが）概念上、必要になります。
レンダーオペレーションというのは「対汎用レンダーシーケンス用の命令データ」と
いうことになるので、 XCube_Root が XCube_RenderSystem と XCube_RenderTarget などを
つなぐための「手がかり」ということになります。
統一して片方が消えるのは涙目、というのはそういうことからきています。
ただし、これは現在のレンダーターゲットの持つオペレート的要素をほぼそのままレンダー
オペレーションに移動させて、もう一度原点に立ち返ってバッファとしてのターゲットクラスを
新作するくらいの心意気（つまりある意味で２つのクラスを統一して、同名クラスを後から追加する）
がよさそうです。
そうしますと、
○レンダーオペレーション
どうレンダーシステムを使っていくかの指示がデータの形で書かれたもの
○レンダーターゲット
独自にレンダリングを行う場合にも確保するし、
レンダーオペレーションの対象オペランドのひとつになるもの
という形で、オリジナルに近い整理が可能になります。
「誰か僕とキャッチボールしてくれ～ (ToT)」
と思っていたら豪速球が帰ってきたので痺れました。
上記整理に着手すれば、汎用レンダーシーケンスをもっと分かりやすく図示できると思います。
# そりゃハードコードより汎用シーケンスのほうが煩雑になるのはやむをえないとしても、
# onokazu さんが書かれていたように、本質的にはそんな難しいものではないです
2008/06/26 14:49 K. Ono <ono...@gmail.com>:
--
minahito (mina...@gmail.com)
K. Ono
ちょっと今時間がないので、下記部分だけ返信させていただきます。
> この機構ですが、PDFの50ページ、52ページにあるように、
> タスクからレンダーオペレーションを改修する部分は共通（つまり final）にして、かつ、
> 開発者の拡張を確保するために、 Visitor を交換可能にする予定でそうしました。
>
> このあたりはいらねーぞ！ということになってくれば（なりそうだ）
> onokazu さんの整理案でいってみようと思います
いえ、必要ないとはぜんぜん思わないです^^;
先のリファクタリング案の方でも実際のVisitor処理に関してはそのままになっているかと思います。
これはあくまでも好みもしくは僕個人の問題なので、以下は無視していただいても構いません。^^;
コアのコードを読み始めた時に、最初に行き着くのはXCube_Root::execute()の部分だと思うのです。
その中で一番始めにつまずくのが下記部分だったのです。
$collector =& new XCube_RenderOpCollection();
$rootTask->acceptCollectorAll($collector);
$visitor =& new XCube_RenderableVisitor();
$collector->acceptVisitor($visitor);
print $this->mRenderTargetScreen->getResult();
Visitorを使用しているなというのは分かるのですが、Visitorってその処理を追うのがとても面倒ですよね？
なので、この部分を下記のような感じにしてしまって、
$render_operations =& $rootTask->drawAll();
print $this->$mRenderTargetScreen->render($render_operations);
Visitorパターンで実際にダブルディスパッチしている部分に関しては、Visitor当事者内に
入れてしまえば初めてこの部分を見た人にも直感的で分かりやすいんじゃないかなと。。
もちろん、さらに突っ込んでコードを見ていけばいつかはVisitorの部分にぶつかりますが。。
ただ、この部分はfinal?のような部分ですし、元のままでも全く問題はありません。
どうでも良いと言えばどうでも良いことなんです^^;
決してこのVisitor部分が必要ないということではありませんので。。
K. Ono
> $renderSystem->setRenderTarget($target);
> $renderSystem->setTemplateName(..); // ←これはないけど
> $renderSystem->setAttribute(xxx, xxx);
> $renderSystem->setAttribute(xxx, xxx);
> $renderSystem->setAttribute(xxx, xxx);
> $renderSystem->render();
こちらの方が、「レンダーシステムに描画を依頼する」という意味ではしっくりきますね。
レンダーターゲットにパラメータをセットして、それをレンダーシステムに渡して、
描画結果が再度ターゲットに渡されるというのは少し不思議な動きに思えていましたので。。
レンダーオペレーションがレンダーターゲットを介する必要がないということであれば、
レンダーシステムはfinalではありませんし、レンダーシステムをレンダーオペレーションの
コレクションに対してvisitさせるというのが自然なようにも感じますがどうでしょうか。