ホーム > フォーラム > 開発 > XOOPSの将来

XOOPSの将来
投稿者: tadashi | 投稿日時: 2009/8/2 10:40 | 閲覧: 20889回
tadashi

のんびりした管理人です。

初期からXOOPSに関わってきたものからすると、今は、隔世の感があります。
世の中には多くのCMS、コミュニティポータルがあり、XOOPSでなくてはいけないという
時代は終わっています。

そんな状況の中、XOOPSはまだまだ健在です。
全くのボランティアでやってきたわりにはよくここまで来たものだと思っています。
ただ、これからは、他のCMSと同じ土俵で競争するなら、結構大変ともいえます。
完全にボランティアで、バックアップする企業も明確な形では存在しません。
XOOPSの将来はどうなんでしょうか?

それで本題です。
XOOPSの将来についてですが、私は、明るいと思っています。

minahitoの鯉日記
コンストラクションツールの道
http://d.hatena.ne.jp/minahito_carp/20090721

にあるようにすすめば、非常に面白い状況になると期待しています。

重要なのは、コンストラクションツールとして何が面白いか? というか何をつくるかになります。

現在、見えているのは、
どのWebアプリケーションとも連動するようにXOOPSが発展する。
ことです。

そうなれば、モジュール作者は、XOOPS Cube 用に書けば、MTでも、wordpress でも、
NetCommons でもモジュールが動くようになります。XOOPS Cube を媒介にして動く
からです。もちろん、各Webアプリケーション用に接続用コードを書く必要がありますが、
その接続用コードさえあれば、モジュールの改変は必要ありません。

XOOPS Cube が、Webアプリのハブになるなら、これからXOOPSの将来は明るいです。

コメント(19)

新しいものから | 古いものから | ネスト表示 | RSS feed
Re: XOOPSの将来 
投稿者: kuroasika | 投稿日時: 2009/8/2 23:56
kuroasika

XOOPSコア・モジュールの開発者のみなさまには大変感謝しております。
私は紙媒体のデザイン畑出身で、PHPってなに?ぐらいの人間です。
確かに今は、XOOPSよりとっつきやすいCMSも多数あるのではないか?(他の使った事がないのでよく分からないのですが・・・)と思いますが、これだけ多様なモジュールがそろっているXOOPSだからこそ私のやりたい事もできるのではないかと思っております。

いまさら私自信がモジュール開発などできるとは思っておりません。
一個人で、高い報酬を支払ってサイトをつくってもらう事もできません。
そんな私にはXOOPSは希望の光です。

多分、同じ思いの人はたくさんいるはずです。
その中から、いつかは上場するような企業もでて、利益なしでバックアップしてくれるような企業もでてくると思っています。

なにが言いたいかと言うと、XOOPSには他のCMSは気にせず、我が道を行ってもらいたいとなぁと思っております。
すると自然に他のCMSと差別化ができ、将来も明るいのではないかと思います。

ps.見当違いな事を書いていたらすいません・・・。
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/8/3 16:14
onokazu

ちょっとこの部分気になりましたので。。

引用:
現在、見えているのは、
どのWebアプリケーションとも連動するようにXOOPSが発展する。
ことです。

そうなれば、モジュール作者は、XOOPS Cube 用に書けば、MTでも、wordpress でも、
NetCommons でもモジュールが動くようになります。XOOPS Cube を媒介にして動く
からです。もちろん、各Webアプリケーション用に接続用コードを書く必要がありますが、
その接続用コードさえあれば、モジュールの改変は必要ありません。

XOOPS Cube が、Webアプリのハブになるなら、これからXOOPSの将来は明るいです。


確かコアの開発等ではこのような話はまだ出ていませんでしたが、何かありましたでしょうか。

ちょうどPluggがやろうとしていることとかなり似ていましたので^^;
XOOPS Cubeのコアがこのように開発されるのも面白いかもしれないですね。

ところでtadashiさんはNetcommonsは今後もMojaviベースで行くのかどうかご存知でしょうか?
Mojaviの開発は既にほぼ停止している状態ですし、以前のようにXOOPSベースだと上のような
対応もかなり楽だったと思うのですが。
Re: XOOPSの将来 
投稿者: tadashi | 投稿日時: 2009/8/3 22:36 | 親コメント: #20061
tadashi
引用:
確かコアの開発等ではこのような話はまだ出ていませんでしたが、何かありましたでしょうか。

前から、私が言っているだけですが、聞いた人は、面白いと思うようです。
2年くらい前から、いっているので段々現実味でてきているのではないでしょうか?

引用:
ちょうどPluggがやろうとしていることとかなり似ていましたので^^;
XOOPS Cubeのコアがこのように開発されるのも面白いかもしれないですね。


誰でも考えることは同じなんではないでしょうか? その方向に動けばいいと思っています。
minahito さんの考え方によれば、なんでもありなんで、この方向に多くの人が流れれば
面白いところです。
XOOPS Cube ルネッサンスはやりたいところですが、急いではいません。
コミットする会社がでてこないと難しいですからね。

引用:
ところでtadashiさんはNetcommonsは今後もMojaviベースで行くのかどうかご存知でしょうか?
Mojaviの開発は既にほぼ停止している状態ですし、以前のようにXOOPSベースだと上のような
対応もかなり楽だったと思うのですが。


maple ですよ。
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/8/4 0:03 | 親コメント: #20063
onokazu
引用:
引用:
ところでtadashiさんはNetcommonsは今後もMojaviベースで行くのかどうかご存知でしょうか?
Mojaviの開発は既にほぼ停止している状態ですし、以前のようにXOOPSベースだと上のような
対応もかなり楽だったと思うのですが。

maple ですよ。


失礼しました。mapleの間違いでした。ただ、開発がほぼ停止しているというのはそのmapleのことを
言いたかったのです。今後Netcommonsはどのように展開してくのかなんとなく興味ありましたので。。
Re: XOOPSの将来 
投稿者: tadashi | 投稿日時: 2009/8/4 9:48 | 親コメント: #20065
tadashi
引用:
失礼しました。mapleの間違いでした。ただ、開発がほぼ停止しているというのはそのmapleのことを
言いたかったのです。今後Netcommonsはどのように展開してくのかなんとなく興味ありましたので。。


こんごどうなるかはきまっていないところが多いですね。

開発リードの新井先生なしでもプロジェクトが進む方向にまずはもっていくことが大切だと思っています。

システム開発という観点からいくと、
モジュールをよりつくりやすくする方向がいま重要ですね。
Re: XOOPSの将来 
投稿者: minahito | 投稿日時: 2009/8/26 9:53 | 親コメント: #20061
minahito
引用:
確かコアの開発等ではこのような話はまだ出ていませんでしたが、何かありましたでしょうか。


一応、BASEまたぎの方法論は例のタスクシステムを含めて色々検証中です。
もともと XCL 2.1 の頃の XC で言っていたつもりのことをまだしつこく目指しているのですが、あの頃は僕はIT語が喋れんかったので色々意思疎通で問題ありました。
最近はだいぶ勉強したので大丈夫です(錯覚

どこまでがファンデーションで、どこからがライブラリで、どこからがキットで、どこからがカスタマイズ、開発で、どこまでがランタイムでどこからがツールの領分なのか……
こっちは通信アーキテクチャで、こっちがオフラインツール用定義、こっちはプロダクティビティ用アーキテクチャで……
みたいなのは、昔と比べて相当整理できてきてると思うんで、

もっぺん目論見ドキュメントを書き直せば、今度はうまく伝えられるかもしれません。
なんかこのプロジェクトのコレみたいなドキュメントを書くべきだよ!というのがあれば教えてください。

XCみたいなバックボーンを「アセンブリフレームワーク」と呼ぶらしく!?
そこも含めて、コレはアレのためにあるけど外せるとか、コレはナニと相性悪いけど必要なんだとか、いちいち書けると思います。

最近のゲームエディタとインディーズゲームの状況見てますと、簡素なランタイムとツール通信用定義があればWebでも同じことができるはずだという気分が盛り上がってまして、昔頭に思い描いていた「コンストラクション」より何段も上のことに取り組んだら面白いだろうなぁと思っとります。
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/8/27 16:20 | 親コメント: #20096
onokazu

アセンブリフレームワークというのもWEB関連の知識しかない自分にとっては初耳です^^;

今までのお話からすると、フレームワークのフレームワークのようなものを目指されているのかなというのを何となく理解しています。

ただ、minahito_sandboxを拝見した限りは、XCのコアはWEBでMVCフレームワークと呼ばれているものそのままなので、これが今後どのようにしてアセンブリフレームワークというものに変貌していくのかなというのは少々あります。
Re: XOOPSの将来 
投稿者: minahito | 投稿日時: 2009/8/28 14:25 | 親コメント: #20098
minahito
引用:
アセンブリフレームワークというのもWEB関連の知識しかない自分にとっては初耳です^^;


僕もこないだ初めて聞きました。;;
なにがしかの定義に基づいたテクニカルタームではなく、アセンブリという形容詞がついたフレームワークなのかもしれません。

仮に Cocoa Framework がそうなのだとすると(そうだと言われてる)、フレームワークのためのフレームワークというより、フレームワークの枠組みが使用するコンポーネントによって変化するという印象です。これは開発側からみれば「設計上絶対外せないもの以外は、基本的に外せること」という言い方ができると思います。

引用:
XCのコアはWEBでMVCフレームワークと呼ばれているものそのままなので


とはいえ、実は厳密な意味での M も C もまだありません。。。;;
でも今後 M を追加したときに、それを使用しなくてよい、という形にするとアセンブリフレームワークになるのかなと思います。なんにしても、「ツール用に基準として用意するが選択の自由と共存しますよ」ということをヨソの言葉で説明できるのでちょっと心が軽くなりました。

Optional Class Library と Optional Framework の区別はシーケンスを持ってるかどうかで区別しようと思います。 M はシーケンス持ってないでしょうけど...

XC の設計の元は OGRE なんですが、これまではコア自体がモジュールで構成されるというイメージはしっかりもってました。ただ、がっちりしたシーケンスは BASE でやるのか、コアが最低限の共通項を(対ツール向けに)用意するのか線引きが常に微妙でした。今は、とりあえず用意して「アセンブリフレームワーク」って言っときゃいいんだという感じなんです。(^^;
Re: XOOPSの将来 
投稿者: minahito | 投稿日時: 2009/8/28 14:40 | 親コメント: #20100
minahito
引用:
ただ、がっちりしたシーケンスは BASE でやるのか、コアが最低限の共通項を(対ツール向けに)用意するのか線引きが常に微妙でした。


追記なんですが、 1.0 でこのへんを延々と思案していた理由として、
開発ツールをフリータイムに作っていくのが自分がかつて想像していたより 100 倍くらい大変だったというのと、
そこそこの(≒作ってておもろい)開発ツールをマルチプラットフォームアプリとして作るとウィンドウシステムから手を入れないといけない、
というのが理由です。

そうすると 0.9 のように、 BASE ごとに特定の仕組みを作ることを推奨して、同時に「ツールもBASE毎作ってください」とはとても言えないと。コマンドラインツールのようなものはともかく、 cubson GUI Force クラスの(あれはジョークとしても)ツールは開発だけで複数年もかかるし、一度書いたら他の BASE でも使える部分がちょっとはあるって具合にしないと周辺のツール開発が PHP コードに追いつかない状況になってしまうと思いました。あと独立したツールは言語が変わっても使えますしね。

だから XC コアがモデルクラスを持つと、それ自体に議論が生じるのは百も承知なんですが、
やっぱりエンティティエディタとかは XC のセンスで、 XC 界に自前で一個欲しい。

そのツールがあれば誰でもデータ引けますから。だから XC コアのモデルクラスは、ツールとやりとりするためのプロキシだと思ってくれ、という感じで BASE 側に提供したい。そのうえで使うか使わないかは BASE 側の自由な判断にゆだねる、という方向へ持っていきたいです。
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/8/28 16:20 | 親コメント: #20100
onokazu
引用:
引用:
XCのコアはWEBでMVCフレームワークと呼ばれているものそのままなので

とはいえ、実は厳密な意味での M も C もまだありません。。。;;


MVCフレームワークというのは最近は言わないかもしれないですね^^;
WEBアプリケーションフレームワークでしょうか?


引用:
でも今後 M を追加したときに、それを使用しなくてよい、という形にするとアセンブリフレームワークになるのかなと思います。なんにしても、「ツール用に基準として用意するが選択の自由と共存しますよ」ということをヨソの言葉で説明できるのでちょっと心が軽くなりました。


Zend Frameworkとかも、それぞれのライブラリが独立性を保っていて、必要な時に必要なものを使用するというような設計だと思います。それほど多くのフレームワークを見た訳ではありませんが、フレームワーク内の各ライブラリがライブラリ間で依存しないようにきれいに分けられている(それにより必要なものを必要な時にだけ利用できる)というのはあるのではと思います。
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/8/28 16:22 | 親コメント: #20101
onokazu
引用:
だから XC コアがモデルクラスを持つと、それ自体に議論が生じるのは百も承知なんですが、
やっぱりエンティティエディタとかは XC のセンスで、 XC 界に自前で一個欲しい。

そのツールがあれば誰でもデータ引けますから。だから XC コアのモデルクラスは、ツールとやりとりするためのプロキシだと思ってくれ、という感じで BASE 側に提供したい。そのうえで使うか使わないかは BASE 側の自由な判断にゆだねる、という方向へ持っていきたいです。


オプションということであれば問題ないと思いますが、ORMもそれなりのものを開発するにはかなりの時間がかかるのではと思います。少し考えを変えて、既存のORM用のエンティディエディタを内包したXC用モジュール開発ツールのようなものではダメなのでしょうか^^;
Re: XOOPSの将来 
投稿者: minahito | 投稿日時: 2009/8/28 16:49 | 親コメント: #20103
minahito
引用:
ORMもそれなりのものを開発するにはかなりの時間がかかるのではと思います。


はい、うまく伝わっていなかったかもしれませんが、ORM自体は作りません。というか作れません...(-_-)
ただし、既存のORM用のエンティティエディタということになると、フルスペックのRDBMSデザインツールになってしまううえに、対象ストレージがRDBMSになってしまうので XC 的には都合が悪いのです。ちょっと志の低いモデル層を仮定して対ツール規定とし、実装は既存のORMをバインドして使うというのを考えてます。

onokazuさんが言われてるのは「既存のORMを使って、それ用のエディタを書けば短く済むのでは」ということだと思うのですが、
それより、さらにヘボくて、開発時間が短く済むような計画です。;;
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/8/29 10:26 | 親コメント: #20101
onokazu

個人的な意見なので無視していただいて構いませんが、XCのコアは抽象クラスではなく、インターフェースであり続けて欲しいなと思っています。ここで言う「抽象クラス」および「インターフェース」は例えであり、実際の抽象クラスやインターフェースではないです。

どういう意味かと言いますと、各モジュールはXCのコアが提供する「抽象クラス」を実装して開発されるのではなく、XCコアが提供する「インタフェース」を実装することでXCのモジュールとして動作するようになるというスタンスであって欲しいなと。

X2で具体的に言うと、xoops_version.phpという「インターフェース」を通して「実装済みのクラス」である既存のアプリをモジュール化できるような感じです。xoops_version.phpは「インターフェース」であるからこそ、既存のアプリであっても実装が可能でモジュール化できる。もしも「インターフェース」経由ではなく、コアの「抽象クラス」を実装しないとモジュール化できないのであれば既存のアプリを移植するのは非常に困難になるはずです。phpBB、yomi-search、wordpress、pukiwki等の既存のアプリを比較的簡単にモジュール化できるというのはX2の大きな強みであったと思います。

なので、各種ライブラリをオプションとしてコアが用意し、それらを取捨選択して利用するのではなく、コアが提供するインターフェースはモジュール側では必ず実装する必要があるというスタンスの方がコア側にとってもそれらのインタフェースを通して各モジュールへのアクセスが保証されるので、コア/モジュール双方にメリットがあるんじゃないかと。。

また、X2用のモジュール等も移植しやすくなるのではと思います。
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/8/29 10:46 | 親コメント: #20105
onokazu
引用:
引用:
ORMもそれなりのものを開発するにはかなりの時間がかかるのではと思います。

はい、うまく伝わっていなかったかもしれませんが、ORM自体は作りません。というか作れません...(-_-)
ただし、既存のORM用のエンティティエディタということになると、フルスペックのRDBMSデザインツールになってしまううえに、対象ストレージがRDBMSになってしまうので XC 的には都合が悪いのです。ちょっと志の低いモデル層を仮定して対ツール規定とし、実装は既存のORMをバインドして使うというのを考えてます。


なるほど。。エンティティエディタということで、何となくRDBMSようのテーブルエディタのようなものをイメージしていました。そうするとUMLモデリングツールに近いようなものですかね。。

こちらではコマンドラインでモデル層の生成を行っていますが、専用アプリがあると便利ですね。
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/8/29 11:02 | 親コメント: #20105
onokazu
引用:
対象ストレージがRDBMSになってしまうので XC 的には都合が悪いのです。


こちらも最初の頃はXMLファイル等への保存に対応するためとしてRDBMSに限定せず汎用化していたのですが、後でRDBMSに特化するように変更しました。理由は、色々と汎用化が難しくなってきたのと、PHP5では標準でSQLite同梱ということでわざわざパフォーマンスの劣るものをサポートする必要はないかと思いまして。。面倒臭くなったというのもあるかもしれませんが^^;
Re: XOOPSの将来 
投稿者: minahito | 投稿日時: 2009/9/20 13:01 | 親コメント: #20110
minahito

返事が遅くなってすみません。
何度も同じ事を書くようになってしまうかもしれませんが、

引用:
各モジュールはXCのコアが提供する「抽象クラス」を実装して開発されるのではなく、XCコアが提供する「インタフェース」を実装することでXCのモジュールとして動作するようになるというスタンス


フレームワークは積みませんから、コア抽象クラスの実装がモジュール側で必須になる事はあまりありません。それは BASE の選択になると思います。

それはそれとして、高速で効率のよいコールバックが PHP にない以上、パフォーマンス等の理由で、抽象クラスはありえると思います。たとえばC言語では10個のコールバックを設定しなければいけなかったものが、C++では10個の純粋仮想メンバ関数に置き換わった、というのは非常によくあることかと思います。

onokazu さんと真逆の意見になってしまいますが、実質的なフレキシビリティが変わらない以上、どう書くか(スタイル)の問題は、開発者はまず気にしないと思うんです。

複数のコールバックの登録の代わりに、アダプタを書く、というだけの話です。一般的には、という言い方をしたくありませんが、本当によくある、よく見かけることだと思います。

なので、onokazu さんは問題視されておられるようですが、実際には開発者の間ではまず問題視されんだろうと思ってます。やれることが変わらず、執筆量も変わらず、既存の独立したコードベースに手をつける必要もないからです。つなぎをどのスタイルで書くかというだけの話です。

あと、各種ライブラリから取捨選択してほにゃららというところも、
実際コアを作っていく中で、その活用度を立証するサンプルコードも書くんで、捨てずに、すぐ利用できるコードとして提供すれば便利だろうし、みなさんもライブラリを提供してくれますよね。そこから使えそうなライブラリを探して、使えそうだったら使うというのは、これまた非常に一般的というか……

たとえば PHP Render System のような誰でも書くような、またそれがないとすぐに何もできないものは、せせっかくなんだからどこかに放り込んでおけば、捨てるよりいいでしょうし、
確かに"コアを書いた奴が書いたコードなのだから、コアがオプションとして提供している"と見ることはできるかもしれませんが、"周りからコアと思われるから"という理由で製作を断念するのは、ものすごく変な気がします。

なんかこう体裁でごちゃごちゃしたくないのですが、
それでももし体裁が問題になるようなら、ちょっと面倒だけどリポジトリ変更しますが(でも開発中は許して。。。)
これまた実際には問題にならないだろうと踏んでます。

またタスクシステムは onokazu さんが「使うつもりはない、外して欲しい」と書かれてたので、その機能がランタイムに実行されないような設定は可能にしておくつもりです。この取捨選択くらいはあってもよいのではと、、、


あと、インターフェイスだけでなくマニフェストのようなものにもこだわっているのは、ツールキットを統一させるためです。決めごとをインターフェイスだけにしてしまうと、ランタイムでなければ取得できない情報があります=PHPのVMをツールキットに組み込む必要がでて、いよいよ大がかりになります。その情報の永続性も判断出来ないのも痛いです。

これらをプロジェクトで定義することでツールキットの開発を促したい(=PHP VM 組み込みレベルになるとフリータイム開発では事実上実現不可能、なので実現可能なルール作りも併せて行いたい)と考えています。

引用:
phpBB、yomi-search、wordpress、pukiwki等の既存のアプリを比較的簡単にモジュール化できるというのはX2の大きな強みであった


これを現在のコアの仕組みでサポートするためには、コンセプトを丸きり変更しなければならないのですが、、、

現在、実際にメンテナンスされている既存のモジュールの数を考えると全体の数%でしかないと思うのですが、どうなんでしょうか。

いや、「既存のアプリのお気楽ポートが、いまの XOOPS MOD の8割を占めてるんだ!!」ということであれば「す、すすすすすみませんでしたあああああ!!」→設計変更のレベルなのですが、個人的には yomi-search くらいしか active project はないような気がしてます。
Re: XOOPSの将来 
投稿者: minahito | 投稿日時: 2009/9/20 14:00 | 親コメント: #20112
minahito

汎用化が困難(というよりRDBMSのフルフィーチャーが使用出来ない)なのは絶対ありそうですよね。

僕の方は、ローカルストレージの種類を増やすというより、ストレージにネットサービスを利用する可能性(アクセス側になるかもしれないし、公海側になるかもしれない)をふまえて、RDBMS非前提でモデル化したいという考えです。

ウェブサービスにはむしろコントローラをバインドするタイプのほうが多いのは分かっているのですが、モデル層をバインドできるものもあるので、両方あってよいかなと。
(XC間で接続することもあるでしょうし)
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/9/21 11:11 | 親コメント: #20161
onokazu
引用:
汎用化が困難(というよりRDBMSのフルフィーチャーが使用出来ない)なのは絶対ありそうですよね。


モデル層で汎用化するのは難しくないのですが、アプリ側でどうしても特別なSQLを発行したりする必要が度々出てくるので。。その場合にはRDBMSへのデータアクセス層へと直接アクセスしなくてはならなくて、その結果RDBMSのみ対応ということになってしまうことが多いですね。


引用:
僕の方は、ローカルストレージの種類を増やすというより、ストレージにネットサービスを利用する可能性(アクセス側になるかもしれないし、公海側になるかもしれない)をふまえて、RDBMS非前提でモデル化したいという考えです。


確かにそれは面白そうですね。今のところバックアップやメディア置場くらいのイメージしかありませんが、これからどうなっていくのでしょう。SQL対応のものとかも出てくるかもしれないですね。
Re: XOOPSの将来 
投稿者: onokazu | 投稿日時: 2009/11/16 22:45 | 親コメント: #20096
onokazu
引用:
XCみたいなバックボーンを「アセンブリフレームワーク」と呼ぶらしく!?
そこも含めて、コレはアレのためにあるけど外せるとか、コレはナニと相性悪いけど必要なんだとか、いちいち書けると思います。


先程少し調べていたら、このような構成のフレームワークをGlueフレームワークと呼ぶことが多いみたいですね。Glueフレームワークの逆の構成のフレームワークはFull-Stackフレームワークと呼ぶとか。

Zend FrameworkのようにPEARと似たような感覚で使えるのが前者、SymfonyやCakePHPのようにフレームワーク単体で全ての実装を行う必要があるものが後者です。

私自身、Glueフレームワークを作っていますが、今後は置き換えられそうな箇所はPEARではなくZend Frameworkの該当ライブラリを利用する方向へシフトして行こうと思っています。

    投票(4)

    新しいものから | 古いものから | RSS feed
     
      To Top