tohokuaikiのチラシの裏

技術的ネタとか。

XOOPSCubeリポジトリの設計

クライアントは、とりあえずこんなところ。

Chromeを外して自前実装して、Transportをtrueにしてみた。

リポジトリって・・・どうすんだ?

ここまできて、あれー?どうしよう。って。

とりあえず、こんな感じかな?

  1. リポジトリが置いてあるURLをどっかから入手
  2. そのURLは、XMLを返す。そのXMLには、モジュールの在処とか依存関係がセットで情報になったXMLがgzで設置されてる。
  3. クライアントは、そのgzを展開しローカルにXMLを持つ。そのXMLからモジュールを選択して、おもむろに「UPLOAD」ボタンを押すとソースをfetchしてFTPでサイトに接続して、XOOPSモジュールをアップする。この時に、依存関係があったら逐次チェックして
  4. あとは、管理画面に入ってモジュールアップデートなりインストールなりする。

んだけんど、、、

FTP情報+XOOPS情報も取得セナいかんよね。

しかも、FTPでログインした情報と、XOOPS_ROOT_PATHあたりは何の関連性もないから、クライアントにXOOPSサイトの情報として与えるのは

  1. FTPのID/PASS
  2. FTPのROOTからXOOPSのROOTまでのパス
  3. XOOPSの情報をXMLであたえてくれるAPIの場所(もしくは、XOOPS_URL)

ただ、最後の2つは、XOOPSのベースが変わると変わるよね。

これってさ、XOOPSCubeならこのクライアントで一発!みたいにするためには、つまりXOOPSCubeのベースが違うものを使っても行けるようにするためには、APIの場所はBASE毎に違うもんじゃなくて、coreで保障されないといかんよね?

XOOPSCubeの情報を得るAPIは、ここですとか。

そのAPIは、XML2つだけのProxyであってよいんだけど。

<root>
    <apiurl>http://www.example.com/xoopscube/newbase/api.php</apiurl>
</root>

んで、あとはそのapiと通信するっていう。


うーん。


まぁ、とりあえず、Legacyキメキメで作ってしまおうか。


Baseが変われば、あたらしいクライアント作っちゃえばいいんだよ。