あき
attin****@kk*****
2005年 3月 23日 (水) 00:27:28 JST
あきです。 > > ユーザを裏切らないために、V4.0の試作段階ではともかく、V4.0の正式版 > > リリースの際には、コンバート用の対応表のようなものは準備したいですね。 > > 後は、主要なプラグインについては開発者側である程度はリプレースする > > など・・・。多少の有志にも協力してもらって・・・。 > > 現在ディストリビューションに含まれているプラグインについては移植する > つもりです。ただし、一部に「本当に必要か？」と思われるようなものも > ありますので、そういったものは議論の上で外していこうと思っています。 了解致しました。 > > > V3.5は、後先を考えずにいろんな機能を詰め込んできた、というくらいですの > > で、そういった遺産を引きずることは、今後の発展にも開発速度という面に > > おいて影響することが懸念されます。 > > V4.0では、「後先を考えずに・・・」を極力排除し、以降のバージョンでも > > ずっと互換を保っていけるような、そんな洗練された設計を切に望みます。 > > （そうしていきたいです） > > 特に私的には、コア部分とプラグインの棲み分けをキッチリと線引きしたい > > と思っています。 > > 線引きとしては今と変わらないと思います。includeプラグインだけは例外 > で、現在はプラグインでありながら半分はコアみたいな感じになってます。 > （これはなんとかしたいです） 勢いで発言してしまい、申し訳ありません。 『フレームワーク』という言葉が出てきましたので、そういった観点でソース を拝見させて頂きました。（「何を今更」と言われるかもしれませんが） 私が気にしていたのは、プラグインによってはかなり深い部分まで立ち入ってい る部分もあり、このような状態ではたとえどんなにしっかりとした骨格を作って も、互換性をとり続けることは困難であろう、という点でした。 その対策として、コア側では１枚のレイヤー（一般的にはAPIだとか、コンポー ネントだとか）を設け、プラグインには原則そのレベルにまでしかアクセスを 許さない。それ以上は互換性の保証対象外とする。 といったふうにすれば棲み分けが出来るであろうと考えていたのです。 さすれば、プラグイン開発者は互換性を気にせずプラグインを開発でき、 コア側としてもプラグイン開発者向けのコンポーネント開発や、新機能開発に 専念できるであろうと・・・。 しかしどちらかというと竹添殿の考えは逆なのですね。 そいうたレイヤーを設けると、むしろ性能（速度）面が問題になってくる。 ただでさえ速度を気にしてるのにこれ以上遅くなる要素など入れたくない、と。 おおかたそんなところかと思います。 開発可能なプラグインの種類、私はパラグラフとインラインくらいしか知らなか った（他にもあるのは知っていたが、興味が無かった）のですが、意外とじっく り見ると使えそうなものがありますね。 基本的にはベースの機能の殆どを塗り替えることが可能なほどでしょうか。 つまりは、表面的な部分から根っ子の部分に至るまで、いかようにでも料理して 下さい、というスタンスだったわけですね。 自由度が広い分、パワーも必要な考え方かもしれません。 互換性を保つことは、むしろ開発の妨げになるような気もしてきました。 難しいところですね。 > > それをどのように実装するのかまだキチッとは見えていてませんが、レイヤー > > 化は必須だとみています。 > > > > 竹添殿： > > 以前に「これ以上の抽象化レイヤーは増やしたくない」と発言されていたこと > > がありましたが、それはこういったレイヤー化は設けたくない、ということで > > しょうか？ > > 私が発言したのは、「用意しても誰も使わずに性能低下の原因となるだけ > のレイヤは設けたくない」という趣旨のものです。ここで仰っているレイヤー > というのはどのようなものでしょうか？ 既に考えは伝わったか、と思いますが、念のため私がイメージしていたものを 記載しておきます。 私がいうレイヤーとは、ネットワーク階層モデルのような、あるレイヤの機能は、 それより下位のレイヤの機能の集合体によって構成され、また、そのレイヤの 機能は、それより上位のレイヤによって利用される。 ネットワーク階層モデル 第7層 アプリケーション層 第6層 プレゼンテーション層 第5層 セッション層 第4層 トランスポート層 第3層 ネットワーク層 第2層 データリンク層 第1層 物理層 といったものです。 プラグインが手を出せるのはこの階層まで、と線を引けば、コア、プラグイン 共に、相手の取り分についてはあれこれと考える必要がなく、自分の取り分に 専念できるのでは？ と思っていた次第です。 このようにすれば、将来互換を保ち続けるのも比較的に楽にできますよね。
Fork