PukiWiki fork 向け試案

※ まずはじめに、この日記はおれが fork したる!という意思表示ではありません。お間違えのないよう。

pukiwiki.org ドメインが for sale になりましたな。

確認できるのは

  • 増井氏が pukiwiki.jp を取得し、死んでた users-ML に報告
  • heno氏は dev の開発日記に書き込み

やりとりする気なさそうに見えるなぁ。というか pukiwiki.org のサイトは通常の状態では閲覧不可能なのに、なんでいつまでもここにどんどん書いていくのかな、heno 氏は。hosts 書き換えれば見ることができるっていうのと、そのまま使い続けていくのとは別な話だと思うんだけど。

というか、開発以外の話なんだし、自分で blog 用意してそこに書いてくれるのがいちばんありがたい。

  • fork しようかという動きもあるが、愚痴を言う場所になりつつある感じ? つまり 2ch の PukiWiki スレがもう一つできたようなもんか?

ただ、個人的には fork は悪いアイディアじゃないと思う。サーバ管理やサイトの運営ポリシーの問題を除いてもおおざっぱに

  1. PukiWiki 内部に非常に手を入れにくい作り
  2. アップデートしにくい作り
  3. 設定ファイルやコード中のコメントが日本語じゃなくて敷居が高いなどの問題

があるわけで、これをどうにかしようと思ったら、

  • Wiki 記法のパーサ以外全とっかえ

でいいんじゃないかと思う。1というわけで以降は fork する人向けメモ。(あくまで自分で fork するぞ宣言でないことに注意。)

まず、PukiWiki 全体で global 宣言しまくりで、名前空間がフラットで、それを避けるために関数名とかやたら長くなったりして、超やな感じなので、これはもう全部クラスに分けちゃう2。あとアップデートしにくいのと設定ファイルの問題は

  • 設定ファイルの役割を最小限に絞って、あとは全部 Web インターフェイスで設定するように変更する

で、その設定情報がデータ領域に入るようにすれば、設定ファイルの中のコメントが英語だとかアップデートしにくいだとかの問題を一挙に解決できる、はず。特にコメントの問題は単に設定ファイルがでかすぎるのが問題なんだと思っている。あんだけでかけりゃそらコメント要るし、コメントがすぐ読めなきゃそら面倒くさくてやっとれんて話ですよ。

  • そのためには認証周りをもっと扱いやすくしないとダメ

なんだけど、これは前からそうなんだから、この際だからガンバレと。

もひとつ、コード中のコメントが英語でカスタマイズしにくいって問題も、そもそもコメント見ないと何やってるのか分からないような長大なブロックなどが問題なのであって、もっと読みやすいコードにすることが前提にくるべき。あと phpdoc をフル活用する方向にして、それと簡単な図3をサイト上に載せておけば、ずいぶん楽に全体の構造が把握でき、かつそれぞれのパーツの役割も確認しやすくなると思う。

果たしてそれは PukiWiki をベースにする意味あるのか?という疑問は残るけど、自分にとって PukiWiki が PukiWiki であるいちばんの理由は Wiki 記法なので、自分にとっては意味がある。ま、極端な例だと思うけど、しっかりした何かがベースにないと fork できないままで終わると思うし、fork しない方がいいんじゃないかと思う。

  1. 実際には細かく見ないとどこを使ってどこを捨てるかは言えないけど。プラグインだってどれが現在進行形でメンテされててどれが obsolete かもよく分からないし、ここらでご破算にして整理してもいいと思う。 

  2. 実際には 1.4 以降はあちこちで class は導入されているので、あとはコアの部分をどうするかという問題だけかもしれない。プラグインの設定をその中に定数で書くってのもやめた方がいいな。 

  3. どのクラスとどのクラスがどう絡んで何やってる、っての。別に UML とかそんなの要らないし、あっても嬉しくない。 

More