マニフェスト仕様のディスカッション

[minahito]

http://sourceforge.net/forum/forum.php?thread_id=1931794&forum_id=537172

minahito です。

とりあえず１月はスライドでお茶濁しになりそうなのですが、ケツは変えないつもりなので、そろそろマニフェストの仕様を本格的に詰めていかないといけません。

マニフェストは XCL ではファイル複製をしないとモジュールの複製化ができないので、それほど魅力がないと思うのですが、ファイル複製を必要としないであろう次の
BASE からは重要な仕様になってくると思います。

お話を始める前に、マニフェストの意味を整理しておきますと、

1. ツールの自動的処理のための情報を書く場所
2. 連絡先等 xoops_version 的な情報も含む
3. BASE 単位での書式拡張はできるが Cube のリザーブもある
4. ini.php 形式をとる
5. C++ などで読み取る必要があるので、PHPがなと評価できない動的値は禁止

という形になるファイルです。

その関係は先日のスライド（の修正版^^;）にありましたように、
ツールで XOOPS Cube 関係のプログラムをパースして処理させるのは難しいので、
プログラム単位のまとまり（すなわちモジュール等）にマニフェストを出させて、
そのマニフェストを機械が読み取って自動処理を実行するという関係になります。
複雑な処理は外にやらせようということです。

マニフェスト情報から専用のアプリケーションを用いて配布サイトに接続してアップデータを取得したり、マニフェスト同士を比較してモジュールの依存性解決を自動的に行うツールを開発することが当座の目標になります。

自分が専用ツールにさせたいと思っている仕事（最終スペック）は、

[A. アップロード編]
- ＦＴＰクライアントの機能を持ち、マニフェストの記述に従った位置へアップロードする

[B. アップグレード編]
- サイトにアップされているマニフェストから、配布サイトの URL を調べる
- 配布サイトの XML を読み取り、マニフェストのバージョンと比較する
- 必要があれば XML の指示にしたがってアーカイブをダウンロード
- 作者は並行してベータ版やアルファ版を配布できる。

[C. ダウンロード編]
- xoopscube.org/jp XUGJ などのサイトに接続して、推奨モジュールの XML の URL 集を受け取る
- 専用ツール上でダウンロードセンターを実現する

- A のマニフェストは Cube の公式仕様。
- B の XML は Cube からフォーマットを勧告。
- C は Cube からは特になし。
- 専用ツールは XOOPS Cube プロジェクトとしては開発しない。
- サイトプリロードはマニフェストなし、ツール未対応

という感じになると思います。

とはいえ、第一段階でまずやりたいのはバージョン比較とダウンロードの実験。こんな感じでどうだろうと思っているのですが....

<?php
/*

[Cube]

# XCID ... GUID みたいな全体で一意の ID
XCID=GF4X-UYEW-48Y9-3ZC0

# 名前は、故意じゃなくてもぶつかることはあるかも
Name=bxBBS
Version=1.0.0.0
Type={Manager,Addon,Theme}
URL=http://example.com/bxBBS.xml

# 専用ツールにアップロード位置を通知
Style={XCL,Shade,D3}

# あとは装飾的情報
License="The new BSD License"
Copyright="Public Domain"
Authoer="Jhon Carmak"
Support=http://example.com/support/
Contribute==http://example.com/contribute/
Feedback=http://example.com/support/

*/
?>

<?xml encode=...>
<cube>
<archive stable>
<version>1.0.1.0</version>
<url>http://example.com/bxBBS_1_0_1_0.zip</url>
<archive>
</cube>

ご意見、突っ込み、
もろもろお願いいたします。

--
minahito (mina...@gmail.com)

[nobu]

sunday-lab の記事を見てこの話を思い出しました。
(どうコメントしようかと頭を整理してる間にすっかり忘れてしまってた ^^;)

Cube の思想と違って、泥臭い現状のままで自動更新を実現しようと Xoops Update とモジュールとそれをサポートするサービスを作って
います。http://www.scriptupdate.jp/
表現形態は違うにせよ、後付けで manifesto 相当の情報を作ってサーバーに置くことでサービスを実現している訳です。

このサービスを作っていて、不足していると思った情報は次の2点です。

1. どれが新しいバージョン? (バージョン番号だけでは判らない)
2. どこへ置けばいいの? (ファイルのレイアウト情報)

Xoops Update では、1 をアーカイブ内のファイルの最新タイムスタンプを元に作成、2 は人間が XOOPS_ROOT_PATH を元
に再パッキングして解決しています。この議論の manifesto では、そこも含めて自動化可能な情報をツールに与えるのが狙いでしょうから、この
辺を仕様に含めると良いと思います。

%% forum ではコメント半分で力尽きました。 ^_^;

[minahito]

minahitoです。
お疲れさまです。

nobuさん貴重な情報ありがとうございます。

> 1. どれが新しいバージョン? (バージョン番号だけでは判らない)

これはフォーラムにも書きましたが、
バージョン番号の付け方自体を「仕様化」して、必ず機械の都合に合わせてもらうことをルールに
しようと考えていたのですが、これでもまだ甘いでしょうか？

10.1RC などは人間的な表記名であって、機械に処理させるためには、
10.1.0.1 など必ず番号にしてもらうというイメージでおりました。

そして RC やマイナー番号の付け方の規則もこの際、推奨というか仕様を出してしまおうかと……


> 2. どこへ置けばいいの? (ファイルのレイアウト情報)

これはマニフェストの "Style" という場所に、
ファイルパスではなく、「そのモジュールが準じているルール名」を書いてもらい、
ツール側がそのルールを実装するという形で突破しようかと考えていました。

つまり、のちに "D4" というスタイルが登場してマニフェストの文法に登場しても、
あるツールがその "D4" のアップロード方法を実装していなければ、
アップロードはできない……という具合です。

> この議論の manifesto では、そこも含めて自動化可能な情報をツールに与えるのが狙いでしょうから、この
> 辺を仕様に含めると良いと思います。

貴重な情報ありがとうございます。
ぜひ上記の点をふくめアドバイスください。

ツールの方は、とりあえず Win/Mac で FTP の実装はあっちゅーまにできましたが
（最近のプログラム環境はすごいですね……）
なにげに Java アプリにするのが一番いいのではないかという気になっています。
しかし Java は昔ケータイで J2ME を触ったことがあるくらいで、ほとんど分かりません。
誰か「俺は分かるぜ！」という方おられますか？

あと、 SFTP とかが使えないと実は使い物にならないのかなぁという気がしています。
これも Mac だとライブラリが提供されているのですが、 Win だと今のところさくっと実装
する方法を見つけていません。

[nobu]

機械的に扱うならバージョン情報は、シーケンシャルな数値(整数)で
表すのが楽だと思います。パースとか不要になります。

forum のコメントのように

Version=1.0.0.4 // Sequence Number for Machine Parser
Disp_Version=1.0rc // Version Name to Display

なんてするなら、

Version=1.0rc // Version Name to Display
Sequence=2008030701 // Version for Machine

なんて定義しても同じことですよね。
シーケンシャルと言っても連続値である必要はなく上記の例は、
"日付+2桁" を想定しています。(DNS の設定で使われるコンベンション)

ファイルの置き場所については、それが規定の一部となるなら何も問題
ありません。現状は、その規定がないので、レイアウトの正規化が別に
必要になると言うだけなので。

[minahito]

minahito です。

> Version=1.0.0.4 // Sequence Number for Machine Parser
> Disp_Version=1.0rc // Version Name to Display
>
> なんてするなら、
>
> Version=1.0rc // Version Name to Display
> Sequence=2008030701 // Version for Machine
>
> なんて定義しても同じことですよね。

逆に

Version=1.0rc // Version Name to Display
Sequence=2008030701 // Version for Machine

なんてするなら、

Version=1.0.0.4 // Sequence Number for Machine Parser
Disp_Version=1.0rc // Version Name to Display

なんて定義しても同じことと言えます (^^;
ちなみに Disp_Version は無くて構いません。
（というか機械は使いません）

ここのパースは手間というほどのことはありません。
比較も上のくくりから比較していけば良いので楽です。
.NET とかはこの４つに区切られたバージョン番号を採用していますが、
ネットワークアップデートのあるソフトなども単純にバージョン番号で比較
することが多いかと思います。
（個人的にはそれ以外のケースは知らない）

「β版」とか「RC版」といった情報はそういうシステマティックなバージョ
ン番号では扱えないので（これは Legacy などでも同じ）

そういう必要があるなら Disp_Version を用意するけど、
なくてもいいし（マニフェストに書く事じゃないし）
機械的には Version しか見ないよ、という仕様でいいかなと……

逆にシーケンシャルな数値だとリビジョン番号のように自動生成するならよい
のですが、
日付＋バージョン回数とはいえ、
定期的に書き換えるものなので MMDD を書き換えたけど YYYY を書き換え
忘れたとか、
その数値を書き換えた後で、バージョン番号も書き換えなければならないとか
あるので（その２つの情報を紐付けしたい場合は自己管理になる）

そこまで機械に寄って貰わなくても大丈夫かなと……

単純にバージョン番号に a とか c とか RC とか入れられないというだけで、
XXX.YYY.ZZZ.WWW で容易に比較ができます。別にこれを西暦、月、日、
リビジョンにあてはめてもいいかと思いますが、バージョン番号ひとつで
管理がつけば色々楽ではないでしょうか。

08/03/07 に nobu<nobuhiro...@nifty.ne.jp> さんは書きました:

--
minahito (mina...@gmail.com)

[nobu]

> Version=1.0.0.4 // Sequence Number for Machine Parser
> Disp_Version=1.0rc // Version Name to Display
>
> なんて定義しても同じことと言えます (^^;
> ちなみに Disp_Version は無くて構いません。
> （というか機械は使いません）

これはその通りです。でも dot 区切りの順番解釈が明解とは言えません。
例えば、次のバージョンあったら順番はどうなるでしょうか?

1.2, 1.10, 1.11

これが XOOPS のモジュールだと、

1.10, 1.11, 1.2

となると期待しないでしょうか?

厳密に解釈を定義すれば問題ないと思われるでしょうが、それでは現状
既に使われているバージョン付けルールの変更を強制することになります。

どうせ新たに定義するのだから、Version なんて既に別の意味で使われ
てるものは使わず新たなフィールドを使っても同じことでしょう。

と言うことで、Version を人間向けにした方が混乱しないと考えています。

[minahito]

minahito です。

> これはその通りです。でも dot 区切りの順番解釈が明解とは言えません。
> 例えば、次のバージョンあったら順番はどうなるでしょうか?
>
> 1.2, 1.10, 1.11
>
> これが XOOPS のモジュールだと、
>
> 1.10, 1.11, 1.2
>
> となると期待しないでしょうか?

XOOPS Cube Legacy の時点で、バージョン解釈は厳格化されています。

http://xoopscube.org/modules/pukiwiki/index.php?cmd=read&page=XOOPSCubeLegacy%2FReference%2Fxoops_version&word=xoops_version

1.2 と書くのは仕様からいくと違反で、
1.20 か 1.02 と書かなければいけません。
もし 1.2 と書いた場合は 1.20 と解釈されます。

（フェイズドアップグレード機能のために厳格化された仕様です。
　Legacy ではバージョンの比較は結構何カ所かで使っていますので...）

基本的に XOOPS2 の仕様に引っ張られるのは Legacy までで、
XOOPS Cube で作っていく仕組みは、新たにやってきた技術者に、
「これなんでこんなことになってるの？」
と質問されたとき、
「いや、それは XOOPS2 という時代にこういう曖昧なことがあって……」
というようなエクスキューズをしなくて済むものを目指します。

.NET 等と同様の４桁バージョン表記もそのひとつですが、
一応布石は Legacy である程度仕様を改善した時点で打ってあるので、
この点に関しては大丈夫かなと思います。

もし他にどうしても解決できない問題が出た場合は、
XOOPS Cube 側が譲るのではなく、
Legacy などの拡張チャンクを取り付けて、そこに補助情報を加えて回避する
方法をとるつもりです。

--
minahito (mina...@gmail.com)

[K. Ono]

小野です。

番号や日付だけでの比較はちょっと単純すぎるような気がします。

例えば、

2007/12/01　1.3.0アルファ版リリース
2008/01/01　1.1.0正式版リリース
2008/02/01　1.2.0ベータ版リリース

があったとして、バージョンでの比較だと1.3.0アルファ版がインストールされ、
日付での比較だと1.2.0ベータ版がインストールされてしまいます。

機械に自動的にやらせるにせよ、人間に選択させるにせよ、アルファ／ベータ
のような情報はどこかで必要になるのではないかと思います。このツールが
正式版のみを対象にしているということであれば、問題はないかもしれませんが、
ベータ版やアルファ版をいち早く導入したいような場合もあるのではないでしょうか。

PEARなんかはバージョン番号のほかに、安定度の目安としてstable/beta/alpha/develとか
用意して、ユーザの希望に合わせてインストールされると思います（ユーザの希望が
stableの場合は上の例の1.1.0正式版がインストールされるなど）。

このようなツールですが、PEARを使えばサイトの管理画面上で似たようなことが
できるのではないかと思います。ちょっとまだ構想段階ですが、Xiggのプラグイン
管理とかでテストしてみる予定です。

[minahito]

minahito です。

> 機械に自動的にやらせるにせよ、人間に選択させるにせよ、アルファ／ベータ
> のような情報はどこかで必要になるのではないかと思います。このツールが
> 正式版のみを対象にしているということであれば、問題はないかもしれませんが、

マニフェストがアルファ版かどうかの情報を含める必要はなくて、
一番最初のメールに書いたように、
マニフェストがアクセスする先にある XML ファイルにそのような情報を持たせて、
ユーザーに選択させることになりそうです。

<?xml encode=...>
<cube>
<archive stable>
<version>1.0.1.0</version>
<url>http://example.com/bxBBS_1_0_1_0.zip</url>
<archive>
</cube>

ここにたぶん <archive alpha> とか入るのかなぁ……と

バージョン番号規則はきちんと定めておく必要はあると思います。
アルファだろうがベータだろうが、ブランチでないならきちんと番号を振って管理することです。

1.10 <-- 安定版
1.20.1.0 アルファ版1 <--- DB 変わる
1.20.2.0 アルファ版2 <--- DB また戻る
1.20.3.0 アルファ版3 <--- DB また変わる
1.20.4.0 アルファ版3 <--- DB ついに最終形に!
1.30.0.0 <--- 安定版

ファイルの上げ下げで済む PEAR と異なり、DBの変更があるモジュールはいろいろ大変
なので、この場合は段階的アップグレードの仕組みをモジュール開発者の誇りをかけて
各５段階分作っておけば、 1.10 から 1.30.0.0 に５回の段階アップグレードをかけて正常に
アップグレードすることはできます。

しかしキビキビした開発を考えると

1.10 <-- 安定版
1.30.0.0 <--- 安定版

で考えて、開発に付き合ってくださる方には別途マニュアルを出すというのもひとつの方法
だと思うので、そのへんは XML でアーカイブ情報を発信する開発者次第ってことになって
くると思います。

（たとえばテンプレートの変更で済むようなアルファ版は XML に含めておき、
DB などの実験的変更を伴う場合は機械的な上げ下げの仕組みに乗せない、
という方法もあると思います）

--
minahito (mina...@gmail.com)

[K. Ono]

小野です。

> 2007/12/01　1.3.0アルファ版リリース
> 2008/01/01　1.1.0正式版リリース
> 2008/02/01　1.2.0ベータ版リリース

の例は、もちろんそれぞれ別ブランチ（1.1/1.2/1.3）ということになります。
同一ブランチで上記のようなリリース順はまずないかと思いますので。。

> ファイルの上げ下げで済む PEAR と異なり、DBの変更があるモジュールはいろいろ大変
> なので、この場合は段階的アップグレードの仕組みをモジュール開発者の誇りをかけて
> 各５段階分作っておけば、 1.10 から 1.30.0.0 に５回の段階アップグレードをかけて正常に
> アップグレードすることはできます。

PEARのインストーラですが、独自のタスクを作成することで
特定ファイルに対して特別なアクションを取るようにもできます。
例えば、mysql.sqlというファイルに対しては、現在インストール
されているバージョンのmysql.sqlと比較して、変更されている場合は
alter tableをかけるなどができると思います。

[minahito]

minahito です。

> PEARのインストーラですが、独自のタスクを作成することで
> 特定ファイルに対して特別なアクションを取るようにもできます。
> 例えば、mysql.sqlというファイルに対しては、現在インストール
> されているバージョンのmysql.sqlと比較して、変更されている場合は
> alter tableをかけるなどができると思います。

なるほど……情報をありがとうございます。

ただ、
いまひとつお話の主旨がつかめなかったのですが、(^^;;;

モジュールのアップデートを PEAR のような仕組みに任せてしまう...
（現在のようにモジュールの更新の仕組みをモジュールの中で持つのではなく、
　PEARの機能で実装する）
というお話でしょうか？

それとも単に PEAR はそんな機能があるよ！というお話でしょうか

--
minahito (mina...@gmail.com)

[nobu]

ドット区切りの例を挙げたのは説明を混乱させただけでした。すいません。

言いたいのは、更新順を決めるタグとして Version と言うのは避けた方が
良いのではないか、です。

もちろん、XC での定義はこうだ、と決めれば機械(ツール)は困らないの
でしょうが、人間の側が混乱すると思うのです。

例えば、議論などで「モジュールのバージョンは何ですか」言った場合、
xoops_version.php の version、アーカイブのバージョン、XC の Version
のどれを指すかなんて話になってしまうかなと。

ただ、既にテーマで一部使われているので、次のような動作ではどうでしょう。

Version=1.0rc // 表示名
XcVersion=0.9.9.1 // 機械用バージョン
// XcVersion が省略されていたら XcVersion=Version とする

うーん、定義にロジックを含めるのは美しくない、で却下かな。

[minahito]

minahito です。

> ドット区切りの例を挙げたのは説明を混乱させただけでした。すいません。
>
> 言いたいのは、更新順を決めるタグとして Version と言うのは避けた方が
> 良いのではないか、です。
>
> もちろん、XC での定義はこうだ、と決めれば機械(ツール)は困らないの
> でしょうが、人間の側が混乱すると思うのです。

どうしてもここで意見が分かれてしまうのですが、
僕が知る限り、ネットワークアップロード機能があるソフトウェアはすべてバージョンを
使っており、配信システムがそこを見て更新を行い、トラブルがあった場合はそのバー
ジョンを報告させます。

例によって僕の経験なんてアテにはならないのですが、
ただ結構こういうのは、どこの業界も関係ないと思います。インストーラがアップデー
トの処理を切り替える仕組みもバージョンしか見てませんし、.NET なんかはバージョ
ン番号を埋め込む場所を統一しているくらいですし……

これだけ世の中で使われている仕組みが XOOPS Cube においては、人間の側を
混乱させてしまうというお話が実感としてどうしてもピンとこないというのが僕の感覚
です。

> 例えば、議論などで「モジュールのバージョンは何ですか」言った場合、
> xoops_version.php の version、アーカイブのバージョン、XC の Version
> のどれを指すかなんて話になってしまうかなと。

これはまた Legacy 固有の話になってしまいますが、
少なくとも xoops_version.php と XC の Version はマッピング可能なので数値に
違いは出ませんし、マニフェストの仕様を Legacy に組み込むに至った場合は、
xoops_version.php の $modversion['version'] を必須項目からなくすことも可能です。

またアーカイブのバージョンというのが少し分からなかったのですが、
本来はプログラムの「リビジョン」と、提供されるモノとしてのバージョンは別物で、
アーカイブとして配布されるなら、アーカイブのやり方を間違って再アーカイブした
場合は、番号をひとつ進める必要があります。

これは Legacy では番号の詰まり方の関係から単にやってないだけですが、
４つに分けられたバージョン表記なら最も下のバージョン番号を +1 すれば済む
と思います。

これらもソフトウェア開発における一般的な作業にすぎませんので、人間的に
混乱するなんてことはないと思うのですが……

# むしろ扱う場所が二つに分かれるほうが個人的には混乱します。
# Legacy だけ拡張するならともかく、 XOOPS Cube の本仕様として取り込むと
# 後々問題になる気がします。
# むしろ後日実際に Version で足らなかったときに改定したほうがよいのでは
# ないかと。

ちょっと、

> どうしてもここで意見が分かれてしまうのですが、

があるので (^^;
ほかの方の意見も聞いてみたいです。

また実際のアップデート配信の仕組みで、
バージョンだけで足らず、補足情報を兼用する必要があったケースをご存知であれば
会社をクビにならない程度で情報提供お願いします。(^^;

--
minahito (mina...@gmail.com)

[minahito]

minahito です。
ちょっと整理します。

- マニフェストは新 Base で xoops_version の代わりになるようなもの
新しい Base では xoops_version 的なものとマニフェストを別々に持つ必要はない
- 現在の Legacy のバージョン表記は x.yy 方式で、数値比較を既に導入済
　（リリースしたけどバージョン番号を進めてない...とかは現時点で非推奨）
- マニフェストのバージョンは xxx.yyy.zzz.www 方式
- マニフェストのバージョンは Legacy のバージョンにマッピング可能。逆もまた然り。

これに対して

[nobuさん]
- xoops_version のバージョン管理とマニフェストのバージョン管理は分けるために、
マニフェストから Version を取り除くべき
- バージョンはアップデート配信時の数値比較に使えない

[minahito]
- xoops_version のバージョン表記をなくせば多重管理にならない
- 自分が知る限り、バージョン比較で十分であり、すでに Legacy に導入済みでもある

という感じです。

nobu さんの案でいけば、これから登場する新型 BASE のモジュールも、
Legacy と同様に、マニフェストに書かれたバージョン相当情報とバージョン情報の両方を
多重管理していかなくてはいけません。

僕は、こちらのほうが混乱するので、シンプルにバージョンに一本化したいのですが、
nobuさんからはそちらのほうがユーザーが混乱する（xoops_versionにバージョンを書いて、
マニフェストにまた別の番号を書いたほうが混乱がない）という提言をいただいています。

--
minahito (mina...@gmail.com)

[K. Ono]

onokazuです。

08/03/09 に minahito<mina...@gmail.com> さんは書きました:

> モジュールのアップデートを PEAR のような仕組みに任せてしまう...
> （現在のようにモジュールの更新の仕組みをモジュールの中で持つのではなく、
> PEARの機能で実装する）
> というお話でしょうか？
>
> それとも単に PEAR はそんな機能があるよ！というお話でしょうか

モジュールの管理は現在のような形で行いますが、バックエンドは
pearの仕組みを利用して、ダウンロード／インストール／アップグレードを
行うということになると思います。pearのコア側でこの機能はライブラリと
して既にあるので、XOOPSのコアのライブラリを使うのと同じ感覚です。
ただ、safe_modeとかまた引っかかってくるんじゃないかと思いますが。。

[nobu]

> [minahito]
> - xoops_version のバージョン表記をなくせば多重管理にならない

XOOPS2(XCL) 互換 のモジュールは、マニフェストの対象外と言うことでしょうか?
ならば、私の意見は無視して頂いて問題ありません。互換を捨てて定義し直すなら、
名前空間を分ける必要性はありませんので。

[minahito]

minahito です。

> XOOPS2(XCL) 互換 のモジュールは、マニフェストの対象外と言うことでしょうか?

$modversion['version'] とマニフェストのバージョンの２つが（人間的に）両立できないので
あれば、XCLのほうに泣きを見てもらうことになると思います。
たぶんそれはないと思いますけど。

以前のメールに基本的なスタンスを書きましたが、

> 基本的に XOOPS2 の仕様に引っ張られるのは Legacy までで、
> XOOPS Cube で作っていく仕組みは、新たにやってきた技術者に、
> 「これなんでこんなことになってるの？」
> と質問されたとき、
> 「いや、それは XOOPS2 という時代にこういう曖昧なことがあって……」
> というようなエクスキューズをしなくて済むものを目指します。

XCL プログラムと、これからの新型プログラムのどちらか一方が必ずストレートではない
管理体系を採らなければならないなら、僕は新型の方を優先させる（仕切り直しのチャン
スである新型に XOOPS2 のツケを払わせない）つもりです。

XOOPS2 基準になることに納得がいきません。

とはいえお話としては、
$modversion['version'] とマニフェスト version の両方があると混乱してしまうなら
$modversion['version'] を削るという方法でしのげますよ、ということを書きました。

個人的にはいくらなんでもこの程度で混乱が起こることはないだろうと思ってますので、
$modversion['version'] を削らなくても済むと思いますよ。(^^)

繰り返しになりますが、新型で初めて XOOPS や Web アプリに触れる技術者に対して、
あんまりみっともない仕様にしたくないんです。
「なんでこれマニフェストにバージョン記述ができないの？」
「なんでこれバージョンで比較しないの？なんで俺達が別途管理しなきゃいかんの？」
と聞かれた時、
「えーと、えーと、むかしむかしあるところに XOOPS2 というのがあって……」
というのはいい加減...

それでもどうしても、僕たちXCL開発者/ユーザーに $modversion['version'] とマニフェスト
のバージョンと付き合って行く能力が備わっておらず、対策が絶対必須だ！というなら、

- $modversion['verison'] をマニフェストのバージョンから割り当てる仕組みを Legacy 側
　に導入する
- Version の別名記述を許す（内部的には Version として読み取られる）仕様としてマニ
　フェストフォーマットの勧告を出す

の、
どちらかかなぁ……と。

まとめると、
「ＸＣＬに悪いようにはしない。
　でも別に良いようにもしない。
　仕切り直しのチャンスを生かした新体系が優先」
という感じです。

しかし、この方法にせよ新型BASE側に割を食わせるXCL優先方法にせよ、こういった仕様の
複雑化は、 nobu さんが懸念されている「混乱」が現実に問題視する規模で発生するかどうか
を確認してからでも遅くないのではないでしょうか。

現状では、ユーザーに管理画面でバージョン確認してもらうことすら根付いてませんよね。
ユーザーが xoops_version や Manifesto を直接開いて（しかもマッピング可能な同等値の）
バージョンの区別がつかなくて混乱することが頻発！ってところまで一気にステップアップする
んでしょうか？

# そのうえで、「本当に混乱しますか？」というのがあるんですが。

もちろん開発者ならこれまでの経緯とこれからの経緯を説明すれば、マニフェストを使いたい
開発者がその仕様に沿うことは問題なくできると思います。古い XCL 側が新体系に対して
一歩引いた形になることも、新型側の体系を整えるということで理解していただけると思いま
す。
（そういうことは技術の世界には、往々にしてあるので）

そこをきっちりやっていれば xoops_version のバージョンを報告されても Manifesto のバー
ジョンを報告されても問題ないわけですし。

こういったことが（われわれ人間に）出来ない orz
となったときに初めて対策……でいいと思います。

どうでしょうか！？

--
minahito (mina...@gmail.com)

[K. Ono]

onokazuです。

今回のツールおよびマニフェストなんですが、その新型BASE専用にされては
いかがでしょうか。今までの話ですと、各BASE間でモジュールの互換性は全く
ないということだったと思うのですが、そうであれば、Legacyも含めた全ての
BASEでバージョン管理をcube側で統一させる必要が本当にあるのかなあと
思います。

例えば全てのモジュールをPEARパッケージとして管理するBASEがあった場合、
各モジュールはPEARのバージョン規則を取らなければいけないので、この
マニフェスト用に新たにバージョン番号を付ける必要が出てきてしまいます。

また、このようなBASEの場合、ファイル更新後の処理もPEARのインストーラ
が全てをやってくれるので、ファイルのアップしかしてくれない（？）ような
ツールは必要なくなります。

それともそんなBASEを作ることはできないのでしょうか？ちょっと未だに
minahitoさんの言われる「BASE」の真の意味が理解できていないのですが。。

[minahito]

minahitoです。

> 今回のツールおよびマニフェストなんですが、その新型BASE専用にされては
> いかがでしょうか。今までの話ですと、各BASE間でモジュールの互換性は全く
> ないということだったと思うのですが、そうであれば、Legacyも含めた全ての
> BASEでバージョン管理をcube側で統一させる必要が本当にあるのかなあと
> 思います。

「新型BASE」というのは特定のソフトウェアを指しているのではなく、
これから出るBASEすべてのつもりで書きました。

マルチ BASE は新版で考慮されています。
こないだからガンダーラガンダーラ言ってるのがそれですが、
詳しくは１２月のスナップショットについてるドキュメントや
フォーラムをご覧ください。

http://sourceforge.net/forum/forum.php?thread_id=1851725&forum_id=537172
http://groups.google.co.jp/group/xcube-dev-ja/browse_thread/thread/71cff63d246c0233

あと、マネージャ系はモジュールの形でなくても上げ下げがで
きたほうがいいので、そういう場合にマニフェストが必要になっ
てきます。

マネージャの組み替えや site_*.ini.php を変更しての構築を
担当するのもツールとマニフェストの仕事ですので、 Cube 全
体で最低でも [Cube] チャンクの使い方を揃えることは重要だと
思っています。

> また、このようなBASEの場合、ファイル更新後の処理もPEARのインストーラ
> が全てをやってくれるので、ファイルのアップしかしてくれない（？）ような
> ツールは必要なくなります。

「ファイルのアップしかしてくれないような」事はないですよ。(^^)
単にこのトピックでは上げ下げの話しかしてませんが、
要は人間が機械的にやることを専用クライアントにやらせよう
という考え方ですので、アップデート程度は問題なく自動処理
できるでしょう。
（アップデートの話は書いたつもりでしたが……）

他にも、構築変更もマウスでぐりぐりやりたいし、ボタン一発
で現在のコンストラクションに対応したアドオンを検索してほ
しいし、逆に導入したいアドオンに必要なマネージャがあった
らクリック一発でダウンロードして site_custom.ini.php を
書き換えてほしいし……

そういうことでとにかく色んなツールが欲しい！
そういうツールがどこから自動処理のための情報を拾ってくる
のかといえばマニフェストだ！ということです。

上げ下げに関して言いますと、
あくまで Windows や Mac から操作して、リモート操作を全部
ツールにやらせる感覚なのですが、ダウンロードリストは、クライ
アントに分散している情報を取りに行かせたり、現在使用している
プログラムから使用できるプログラムを絞り込んで検索することも、
クライアントレベルで実装できます。

Cube には正式なダウンロードセンターがないのでクライアント上で
センターもどきを構築してしまうことは結構重要です。

そもそも自動処理って拡張したくないですか？
マニフェストのような形であれば仕様の決まってないチャンクは自由に
使えますから、ＨＤチャンクにＨＤ専用の自動処理や識別に関する情報を
埋め込んでツールにサポートさせることができます。

で、あまりにも低品質な出来で、 extoolsD.dll は見事に失敗し
ましたが、ああいう
「ツールを作るためのライブラリ」
をきっちり作れば、（今度こそ）いろんなツールが出てくると思
います。

以上のような理由から、僕は自前でマニフェストのようなものを
持つことは効果が非常に大きく、 PEAR 単体で直ちに代替になら
ない（というか、根本的に目的が違う）と思っています。

今回のトピックは「上げ下げ編 by マニフェスト」でしたが。

こういうツールをずっと考えていて、
手が出せないでバタバタしてるうちに geeklog に先を越された
んですけど(^^;

http://www.geeklog.jp/article.php/20071223013956671

とにかくサーバーの外からオートで作業すれば、 ID とパスワー
ドさえ預けてくれれば権限云々も関係ないのがいいかなぁと。

> それともそんなBASEを作ることはできないのでしょうか？

そんなことはありません。
単にツールや、これを利用した配信網に乗せられないというだけ
で、マニフェストがないとマズイのはテーマくらいになると思い
ます。
考えているのは構築時にマニフェストの情報を突き合わせる方法
で、起動時に動的にマニフェストの情報を見てビルドチェックを
するのは重いでしょうから……

ただ、テーマだけは Legacy でやってるようにレンダーシステム
の確認が必要なため、マニフェストが必須になっています。

ところで PEAR って書き込み権ないとだめそうなので、
ずっと ssh でログインして PEAR コマンドを叩くイメージでい
たのですが、onokazu さんが考えておられるのはブラウザでボタ
ンを押したら PEAR コマンドのプロセスを走らせるようなやり方
でしょうか？

それだと Apache 権限で実行という事もありそうですよね？
それでちゃんと動くものなのでしょうか。

もし drupal や joolma などの CMS で実際に管理画面から
パッケージの選択インストールやアップグレードを PEAR で行える
ものがあればどんな感じなのかカナリ興味があるので、ご存じであ
れば教えてくださいませ。 m(__)m

# 昔ざっとぐぐってみたのですが...

サーバーの設定が難しそうですが、そうでもないもんでしょうか？

--
minahito (mina...@gmail.com)

[minahito]

minahito です。

> 上げ下げに関して言いますと、
> あくまで Windows や Mac から操作して、リモート操作を全部
> ツールにやらせる感覚なのですが、ダウンロードリストは、クライ
> アントに分散している情報を取りに行かせたり、現在使用している
> プログラムから使用できるプログラムを絞り込んで検索することも、
> クライアントレベルで実装できます。

クライアントの仕様を規定するトピックではないですが、
最初の試作時は木訥なツールを書くしかないと思っていますが、
僕が作りたいと思っているのは、もちろん Wii のショッピング
チャンネルとか、ニンテンドーチャンネルとかのイメージです。

ムービーに落としてみたので、使ったことがなければ是非ご覧
になってください。
とかいって肝心のダウンロードのムービーがアップミスになって
ご紹介できませんけど;;

# また夜にでも...

　検索したりレビューしたり最新情報を見たり
　http://homepage.mac.com/minahito/.Public/Channel.mov

　オマケ:クソゲーを友達に送ることができる
　http://homepage.mac.com/minahito/.Public/Kusoge.mov

↑ここまでの作り込みはとても無理ですけど、
　感覚的にはやっぱりこういうのでしょう！ (^^)

でボタンをポンと押すと
サーバーに接続して上げ下げなり、
site_custom.ini.php への組み込みなりをオートマチックにやってくれる。

（現環境に合致したモジュールを検索するには、今のサイトの構築情報
を取得する必要があると思いますし。たとえば Legacy なら Legacy 用
モジュールに自動で絞り込んで検索するなど）

--
minahito (mina...@gmail.com)

[K. Ono]

onokazuです。

> 「新型BASE」というのは特定のソフトウェアを指しているのではなく、
> これから出るBASEすべてのつもりで書きました。

なるほど、了解です。

> マルチ BASE は新版で考慮されています。
> こないだからガンダーラガンダーラ言ってるのがそれですが、
> 詳しくは１２月のスナップショットについてるドキュメントや
> フォーラムをご覧ください。
>
> http://sourceforge.net/forum/forum.php?thread_id=1851725&forum_id=537172
> http://groups.google.co.jp/group/xcube-dev-ja/browse_thread/thread/71cff63d246c0233

一応フォーラムやドキュメントは全て追っていますが、かなり抽象的なこともあって、
はたしてminahitoさんの真意を完全に理解できている人がいるのかなあと思います^^;
この辺り、ひな形のようなものをこまめに出していただければ助かるのですが。。

> 「ファイルのアップしかしてくれないような」事はないですよ。(^^)
> 単にこのトピックでは上げ下げの話しかしてませんが、
> 要は人間が機械的にやることを専用クライアントにやらせよう
> という考え方ですので、アップデート程度は問題なく自動処理
> できるでしょう。
> （アップデートの話は書いたつもりでしたが……）

なるほど、そうでしたか。。アップグレードの話は書いてありましたが、
ファイル比較以外の件には触れられていなかったと思いましたので。。
アップ後の処理とか設定できるのであれば面白いかもしれないですね。

> こういうツールをずっと考えていて、
> 手が出せないでバタバタしてるうちに geeklog に先を越された
> んですけど(^^;
>
> http://www.geeklog.jp/article.php/20071223013956671

ここって、確かOpenPNEとか色々作っていたところですよね。
いつの間にか対応ツールが増えていますね。

> ところで PEAR って書き込み権ないとだめそうなので、
> ずっと ssh でログインして PEAR コマンドを叩くイメージでい
> たのですが、onokazu さんが考えておられるのはブラウザでボタ
> ンを押したら PEAR コマンドのプロセスを走らせるようなやり方
> でしょうか？

PEARコマンドを呼ぶといいますか、PEARのコアのクラスを使用します。
前にも書きましたが、XOOPSのコアのクラスを使うのと同じです。
PEARコマンドもこれらのクラスを利用しているだけですので。。

> それだと Apache 権限で実行という事もありそうですよね？
> それでちゃんと動くものなのでしょうか。

Apache権限、もしくはスクリプト実行者による書き込み権限は
必要になります。この辺りはファイルをアップロードしたり
オンラインで編集したりするウェブアプリケーションが必要
とする条件と同じになるかと思います。

> もし drupal や joolma などの CMS で実際に管理画面から
> パッケージの選択インストールやアップグレードを PEAR で行える
> ものがあればどんな感じなのかカナリ興味があるので、ご存じであ
> れば教えてくださいませ。 m(__)m

seagullとかでこのような話をしていた（または既に実装済み？）気がします。

今のPEARインストーラはかなり自由に拡張可能な仕様になっているので、
通常のウェブアプリケーションとかでもPEARパッケージにしてしまったり
できるかと思います。ちょっと前のものですが、pearified.comとかで
色々と見ていただけます（phpMyAdminとかあります）。

[氷川霧霞]

氷川です。

週末に東海の勉強会があるので、話題に出して見ます。

残念ながらなんらかのフィードバックが得られるところまでは
行かないと予想していますが、「今こんなことが話題になって
いる、こんな方向に進もうとしている」という認識アップだけ
でもできれば。

資料は作成中。別に話題に出ていたダウンロードセンター
のあたりがあやふやです(^ ^;。
http://www.trpg-labo.com/xoops/manifesto.pdf

[minahito]

minahito です。
氷川さんありがとうございます (^▽^)/
どんどんトピックにしていただけると助かります。

> 資料は作成中。別に話題に出ていたダウンロードセンター
> のあたりがあやふやです(^ ^;。
> http://www.trpg-labo.com/xoops/manifesto.pdf

うおおおおおおお (*^^*)

ダウンロードセンター（仮）は、最初に XOOPS を落としてくるとこ
ろや、モジュール配布サイト（配布サーバー）を検索するための情報
源だと思ってください。

（専用ソフトによって読み込まれる）単なるリンク集の一種と考えて
もらって問題ないかと思います。

# 「Wiiショッピングチャンネル」「ニンテンドーチャンネル」みたいな
# "プログラムの検索とインストール"　　ですね (^^;

08/03/13 に 氷川霧霞<kilica...@gmail.com> さんは書きました:

--
minahito (mina...@gmail.com)

[HIKAWA Kilica]

氷川です。

東海の勉強会でちょこっと話題に出してきました。

昨日は Joomla の人が来ていて、その方からJoomlaのケースを聞きまして、

・Joomlaでは、FTPではなく管理画面からブラウザのファイルアップロードで
　ローカルのアップデートファイルをアップさせる、またはPHPのFTPレイヤを
　使って直接配布先サイトから取ってきてアップデートしている

・理由は、FTPの接続先やオプションの設定をさせるのが結構難しいから
　そこを不要にしたい。

とのこと（十分理解できなかったので、誤解している部分もあるかも）。
確かにブラウザだけで完結できるんであれば、その方がシンプルでいいかも。

ってところでした。

[minahito]

minahito です。
亀レスすみません。

Joomla 情報ありがとうございます。

これも書き込み権を Apache 等に割り当ててるケースですね。
ナルホド...これでいいのか...

これで深刻なセキュリティ問題になったことがないってことでしょうか。
FrontController タイプだから htdocs より上に書き込みするフォルダを作っておけば
いいって話なのかなぁ...

このへんって質問があったら http://www.joomla.jp/ に投げちゃってもいいんでしょうか？ (^^;
（不適当な予感がする）

来られた方って Joomla.jp の管理人でした？

> 確かにブラウザだけで完結できるんであれば、その方がシンプルでいいかも。

BASE の入れ替えやマネージャーの入れ替え以外はできそうな感じですね。
（そのブラウザツールが依存しているものを入れ替えるという操作を受け付けるとマズイ）

マニフェストの仕様が決まればブラウザ版も理論上作れると思います。

# 誰か作って！

08/03/16 に HIKAWA Kilica<kilica...@gmail.com> さんは書きました:

--
minahito (mina...@gmail.com)

[Tom Hayakawa]

Ｔｏｍです。ピンポイントで^^;;

> 来られた方って Joomla.jp の管理人でした？

管理人さんなのかな？
このサイトの管理人に近い存在だとは思いますが、正確なところは良く知りません。
このサイトのNoriさんって方が、先日の勉強会に来ていただけました。

[gondayu]

Drupal 6.0 からコアに同梱された update_status がイメージに近いのではないかなみたいな感じがします。

ログイン >> 管理メニュー >> 入手可能な更新 で 「Drupal 本体のコアパッケージ」 から 「その他のインストールしたモジュール」
まで最新の更新状況を教えてくれて自分の管理画面から最新のパッケージをダウンロードできます。

Joomla! 1.5 は単純に使っている「Joomla! 本体のパッケージ」が最新かどうか知ることができるだけで、「後からインストールしたエ
クステンション（XCube でのモジュール）」の更新状況は判りません（更新状況を知ることは出来ません）。

参考 URL: http://www.drupal-module.info/mod/updatestatus

On 3月12日, 午後12:51, minahito <minah...@gmail.com> wrote:
> minahitoです。
>
> > 今回のツールおよびマニフェストなんですが、その新型BASE専用にされては
> > いかがでしょうか。今までの話ですと、各BASE間でモジュールの互換性は全く
> > ないということだったと思うのですが、そうであれば、Legacyも含めた全ての
> > BASEでバージョン管理をcube側で統一させる必要が本当にあるのかなあと
> > 思います。
>
> 「新型BASE」というのは特定のソフトウェアを指しているのではなく、
> これから出るBASEすべてのつもりで書きました。
>
> マルチ BASE は新版で考慮されています。
> こないだからガンダーラガンダーラ言ってるのがそれですが、
> 詳しくは１２月のスナップショットについてるドキュメントや
> フォーラムをご覧ください。
>

> http://sourceforge.net/forum/forum.php?thread_id=1851725&forum_id=537172http://groups.google.co.jp/group/xcube-dev-ja/browse_thread/thread/71...

> minahito (minah...@gmail.com)

[minahito]

minahito@午前休です。
Tom さん gondayu さんありがとうございます。
亀レスすみません。

> Drupal 6.0 からコアに同梱された update_status がイメージに近いのではないかなみたいな感じがします。
>
> ログイン >> 管理メニュー >> 入手可能な更新 で 「Drupal 本体のコアパッケージ」 から 「その他のインストールしたモジュール」
> まで最新の更新状況を教えてくれて自分の管理画面から最新のパッケージをダウンロードできます。
>
> Joomla! 1.5 は単純に使っている「Joomla! 本体のパッケージ」が最新かどうか知ることができるだけで、「後からインストールしたエ
> クステンション（XCube でのモジュール）」の更新状況は判りません（更新状況を知ることは出来ません）。
>
> 参考 URL: http://www.drupal-module.info/mod/updatestatus

なるほど、結構最近ついた機能なのでしょうか？
となるとセキュリティ関連で成果があがるのはこれからか……

ともかく一度試して感じを掴んでみたいと思います。
なんか他のCMSで「こんなんあったぜ！」というのがあれば
教えてくださいませ m(__)m >ALL

--
minahito (mina...@gmail.com)