Hiroaki Sakuma
hiroa****@sakum*****
2005年 3月 24日 (木) 11:44:00 JST
佐久間です． > > 具体的に動的なプラグインというのは，を条件に条件分岐して動的になるのでし > > ょう > > か？ > > # UserAgentとか？ > > すみません。 > 質問が読み取れません。 > 「どんなのが動的な出力か」、ということでしょうか？ すいません．文字が消えていました．"何を条件に"と書いたつもりでした． > 今思いつくので言えば、サイドメニューやら、ヘッダ、フッタやらでしょうか？ > 以前私がやっていたので言うなら、新着ニュースの表示とかでしょうか。 はい．分かりました． 動的というよりは，他のファイルに影響される，ということですね． mtなどでは，関連する全てのページを再生成しますし，静的なページの出力を行うの であれば，同じようなアプローチが必要だと思います． なお，静的な生成とは少し違いますが，今のCGIではどこでボトルネックとなってい るのかをちゃんと調べると，CGIのままでも相当高速に動作するようになることもあ ります． 例えばWiki文法のパースが重いなら，中間コードをキャッシュするだけでもかなり速 くなるでしょう． また，検索エンジン対策云々の話でも，呼び出すパス(URL)が外から見たときにCGIに 見えなければいいだけの話なので，回避策はいくらでもあります． # PATH_INFO，mod_rewriteの活用など > > Stylesheetを書き換えてもダメですか？ > > ダメというか・・・、不可です。 > そういう話ではありません。 私はWikiに書いた文法に見栄えを求めたことがないので，イマイチ実感がないのも確 かです． ただ，デフォルトで用意されていたStylesheetでは，しっくりこなかったので， Stylesheetを編集して，自分なりにはスッキリしました． > > どうもあきさんはHTML=見栄えまで定義する，という認識で意見を欠かれているよ > > う > > ですが，HTMLのタグというのは，要素がどういう意味を持つか，ということを表 > > すだ > > けなので，どうやって表示されるかはユーザの勝手(自由)です． > > 「だけ」というのは私と考えが違いますが、「そうあるべき」とは理解してい > ます。 > 見栄えを指定するのはスタイルシート、と区別しています。 > ですが、改行をするかしないか、はコンテンツの一部であって、そういった見 > 栄えと混同されるのは不本意です。 > どこで句読点を打つか、どこで段落を分けるか、そういったものの延長だと思 > ってください。 例えば，句読点とからむ話で言えば，禁則処理などもあると思うのですが，そういう のはブラウザによって実装が違うのはご存知ですよね？ 同様に，リスト中で改行する処理に関しても，ブラウザ任せですから，改行コードを 入れれば意図された表示がされる保障はないと思います． > > その辺をちゃんと切り分けないと，タグの挿入するか否かの単純な問題じゃなさ > > そう > > です． > > > > ちなみに，HTMLを出力するアプリケーションであれば，やはりHTMLの規格に準拠 > > して > > 欲しいと思います． > > 私が何か誤解しているのでしょうか？ > <BR>タグが敬遠される理由が分かりません。 > <BR>タグが非推奨タグにでもなったのでしょうか？ > それとも単に、<BR>タグ自体には意味はなく、見栄えのためのタグだから、 > 「良くないのでは？」ということでしょうか？ それを言うつもりはないのですが，Wikiでの改行=HTMLの改行と捉えるべきか，とい うところを議論する必要があります． 私はWikiでの改行=HTMLの改行，という見方は見栄え優先という気がします．Wiki文 法は見栄えを決めるのではなく，文字列の意味を表している(例えば*はリスト要素の 始まりであるという意味)のだと思えば，見栄えのためにBRを挿入するのは矛盾する ことになります． > > オープンソースにしてくださっているのだから，欲しい機能は自分で実装しよう > > とか > > 思わないんでしょうか？ > > 思わないことはありません。 > 自サイトではそうしていますし、「そういった対応をしてくれ」と押しつけて > いるつもりでもありません。 了解しました． > 今回私が「対応すべきじゃないだろうか？」と提案していたのは、後述していた > リスト（箇条書き）に関する部分で「改行をプラグインで記述するとテキスト > ソースが汚くなるんで、何とかならないですか？」といった要望です。 > 延々と書いた、『改行に対応するか否か』論争については、ユーザの要望に対 > する応対の仕方が、要望を出したユーザの方々にはとても納得して頂ける回答や > 対応ではなかったのでは？ > と、（これから一緒に同プロジェクトを盛り上げていくメンバーの一人として） > 書いたまでです。 ユーザに対する対応は，という点はプロジェクトのポリシーなどがあるので，なんと も言えませんが，ユーザの声を聞く気はないし，ポリシーに同意する人が使えばいい， というプロジェクトも多々ありますし，その逆もあるでしょう．もちろん中間もあっ て，どの辺に位置するかはそのプロジェクトによりますが，要望を出した納得する回 答を出すかどうか，ということで言えば，そこまでするプロジェクトはあまりない， と思います． # 実際に，凄いポピュラーな(FSWikiがポピュラーじゃないと言ってるわけではあり # ませんが．Namazuとか)プロジェクトでは，ものすごい数の要望が来ます # 一つ一つ対応したり，納得する回答をしたり，対策をしていると本来の開発が進み # ませんから，要望は極力無視してプロダクトのレベルを上げることで回答する，と # いうアプローチもあります． > もし、今の開発者様が、「私は私の思うカスタマイズでWikiクローンを開発し > ていきますので、気に入った人は使って下さい。そうでない人はどうぞお構い > なく他をあたって下さい」といったような考えの持ち主であるなら、私は早々 > にこのプロジェクトから立ち去るでしょう。 > （いえ、FSWikiに他ならぬ思い入れがありますから、きっとFSWikiをベースに、 > 陰でこっそり自分流のFSWikiクローンを作成し続けることと思います） 竹添さんがどう考えておられるかでしょうが，オープンソースというのは本来そうい うものだと思います． 全ての要望に答えれるわけありませんし，どの要望を聞いてどの要望を聞かないか， というポリシーがないと，プロジェクトを維持しきれません． 一番簡単かつ納得のいきやすいポリシーとして，「作者が必要と思う要望だけ聞く」 というのは，凄く自然なことだと思います． 今後，複数の開発者で作っていくのであれば，開発者の間で要望を取り入れるか否か， ということを議論していくことも必要です．また，今回は1件を取り上げていますが， これが複数だったときは優先度の問題も出てきますし，異なるバージョンを作ってい る場合(最新版とメンテ版など)，どちらへ入れるか，ということもあります． > > > 不要だと思う人は使わなければ良いだけのことです。 > > > > 必要だと思う人は実装すれば良いだけのことではないんでしょうか？ > > それをユーザに？ > FSWikiプロジェクトとはそういうプロジェクトなのでしょうか？ > いえ、オープンソースプロジェクトというものは、みんなそんなものなんでしょ > うか？ > 確かに、過去の発言の履歴を見てみても、そういった側面が見受けられていま > したが・・・。 > （他のプロジェクトを知らないので何とも・・・。でもなんだかどこも同じであ > るような気がしてきました） FSWikiがどうか，というのは置いておいて，オープンソースってのはたいがいどこも そんなものだと思います． 必要と思えば自分で実装する，ことをやっていかないと，人の要望ばかり聞いて，タ ダで(もっと言えば公開にコストが掛かるので赤字で)公開したがる人はいなくなって しまいますよ． オープンソースって今でこそたくさんありますが，基本としては， ・自分が気に入るプロダクトがなかった ・だから，自分流の考えで作った ・せっかくだからソースも置いておくから勝手に使ってよ ・ただし，無保証(要望も聞かないという意味も含めて)だよ ・要望は一応聞くけど，回答は期待しないでね というところが多いのではないでしょうか． 今でこそ，Firefoxのように，多くの人に使ってもらうことを目的としたプロジェク トもありますが，かなり特殊な部類だと思います． もちろん，プロダクトを作る人の中には，自分のために作るというより，多くの人に 使ってもらうことがうれしい，ということが目的の人も居ますので，そういう場合は 要望を吸い上げて，最大限普及するように開発を進めるのもアプローチだと思います． > FSWikiプロジェクト全体を見ていて思うことは、「本当に開発者寄りだなぁ」 > ってことです。 > これだけ魅力があって、これだけ将来性がありそうなのに、その発展の可能性 > を旨くコントロールできていない。そう感じてました。 > これが、もしユーザ寄りの考えに持って行っていけたなら、（「プラグインを > 作れば簡単です」なんて門前払いさえしなければ、）賛同者の数ってグンと > 増えそうなのに、と思ってました。 要望がコアに取り込まれる可能性が高いプロダクト，より，自分でプラグインを作れ ば対応できるプロダクト，の方が需要がありそうですが． プラグインで対応できる，というのはとてもユーザ寄りの考えだと思います．プラグ インで対応できなければ，それこそユーザごとにコアに手を入れていかなくてはいけ なく，ユーザ寄りとは言えません． 作者にとって，プラグイン対応をする，ということは最大にユーザのことを考えてい ると思っていいのではないでしょうか？ だって，作者はいつでもコアに手を入れれるんですから，手間を掛けてプラグインで 対応させるメリットはあまりないはずです． # コアに手を入れたがらない作者も居ますので，一概には言えませんが ===================== Sakuma,Hiroaki hiroa****@sakum*****
Fork