あき
attin****@kk*****
2005年 3月 22日 (火) 00:31:58 JST
あきです。 > ・ページに属性を持たせることができるようにする。ページに付随する > データをページごと移動することができるようにするため。プラグイン > はページに対して自由に属性を追加することができる。添付ファイル > 機能などもページ属性を利用して実装する。 確かに、現バージョンの仕様ではページ管理が辛いですね。 > ・データファイル名にはIDを振る。いまはページ名をURLエンコードした > ものをファイル名にしていますが、長いページ名の場合にファイルシ > ステムの制限に引っかかってしまうためです。IDの振り方やページ名 > とのマッピング方法は要検討ですが… この案に賛成です。 URLが長過ぎるのがひっかかってました。 日本語は結局「〜?page=%B2%F1%BC%D2%BE%D2%B2%F0」てな感じで目で見ても 分からないわけですし・・・。 ところで、FSWikiにはディレクトリの階層を掘り下げて、階層化することで カテゴリ別に管理する、という発想は最初からなかったのですか？ 検討する予定もありませんか？ （単に階層化するだけですと、WikiFarmとかぶってしまいますが・・・） 現状の、ページを作成してからカテゴリを割り振る、というのは、複数の カテゴリに属するページを作成したい場合はいいですが、通常は億劫になるだけ だと思います。 ページ内に余計な行が入るのも嫌ですし・・・。 ま、これは後付でプラグインで対応しようとしたからでしょうが・・・。 > ・ページ一覧は１ファイルに情報を持つようにする。ページのリスティ > ングを行うときにディレクトリ内のファイル一覧を見なければいけない > という点がページ増加時の性能低下の一因になっているため。 つまりこれが結論ですね。 > 手軽に設置できる，ということからは遠ざかるかもしれませんが，RDBMSとの連携は > どうでしょうか． > 大規模になってくると，MySQLなどで管理できると便利だと思うことがあります． > 特に，パーミッションの設定などで手間取るくらいなら，MySQLの方が簡単なことも > 多いです． > 最近のレンタルサーバではMySQLやPostgreSQLが提供されていることが多いですし， > コントロールパネルなどでDBの作成などもできるので，ユーザにとっては敷居が下が > るかもしれません． > # 自分でサーバを構築されている方には手間が増えるかも > > DBとのインターフェイス部分は独自に実装しておいて，プラグインのような形で， > MySQL/PostgreSQL/BerkleyDBなどを切り替えれると便利ですね． > > こういうDBを用意できない人のために，性能を犠牲にしても，最低限の設定で動く > CSV+ファイルなどを使った独自のストア方法も用意しておくという手もあります． 個人的には、FSWikiのPerlのみで動作する、ところに魅力を感じています。 強制的に強いられてしまっては魅力が半減してしまいます。 DBI等を使って、CSV形式でも可（ベースはこれ、設定で切り替え可が理想）、 とするこの案なら賛成です。
Fork