[mixi]フリーの掲示板スクリプトを探しています。 - Let's PHP

ほうほう、楽しいそうですね。
Data形式は、SQLLiteかXML形式で保存していくものがいいのかな？
HTMLも使えて、文字コードはどうだろう？
そこらへんつめていけばできるのでは?

PHPはDBつかうのが簡単だし、DB使うほうがソートだったり、管理だったり融通が聞くからDB版のスクリプトが多く出回ってるのだということはみなさんのコメントからもよくわかるとおもいます。

だからきっと PHPでテキストベースの BBSを実現するためにはDB版以上の労力が必要でとても面倒なんだと思います。

さがしまくってもきっと思うようのはみつからないとおもわれ、、結局自分で作ることになるんじゃないでしょうか。

tak-yさんがなんでDB使わない掲示板が欲しいのかを書いてみるともう少し建設的な意見が出てくるんじゃないでしょうか.

というわけで「自分で作れば」につづく・・・

[11] mixiユーザー 08月26日 18:27

PHPでフォラーム型かつテキストベースに拘るなら
http://kano.feena.jp/erial/clrea/
http://php.s3.to/bbs/bbs6.php
でいいんじゃないかなぁと

＞さまよえるプログラマさん
面白そうですねぇ…。

[12] mixiユーザー 08月26日 18:35

スレッドにならないので案件にマッチしないですが，

http://ralpharama.co.uk/tpf/

昔日本語化しました(更新されてないからそのまま使えると思います)

[13] mixiユーザー 08月26日 18:39

PHP+mySQLとかだったら半日くらいで掲示板つくった経験があるのでお手軽さを考えると、どうしてもSQLを使ってしまうかなぁ、という気がします。
SQLLiteってどうゆうものだろう･･･
調べてみます（苦笑）

[14] mixiユーザー 08月26日 19:08

>>さまよえるプログラマさん

コミュでの開発ですか面白そうですね
やるんならPHPBB並の掲示板は作りたいなー
Data形式は色々選べるようにしたらどうだろう？
SQLite,XML,DB等
文字コードは内部コードがEUC、出力はSJISでいいんじゃないかなと自分は思います。

携帯にも対応できたら面白そう

[16] mixiユーザー 08月26日 19:22

なんか、作る方向に行ってますね・・・
それはそれで楽しそうだ。

最近、
内部コードにユニコード、HTTP上もUTF-8、
ってのが個人的に流行ってます。
いまいちメンドクサイんですけど。

テキストファイルに保存することが好まれる理由のひとつに、
書き込みの削除などの管理業務を手作業でできるってことがあると思います。
本当はこういう管理運用業務は、
管理者用のUIからできるといいですよね。

[17] mixiユーザー 08月27日 01:26

でわ～…tak-yさん仕様でﾏｯﾀﾘと作りましょうか。

■動機を整理してみます。
正直、私も作るならSQLを使って「とっとと」作る派なんですけど、そうやって出来上がったものは…微妙ともいえます。
SQLを知らない人に渡す時には長々と説明しなくてはいけませんし、もしも説明書きを作る…なんて事になったら大変です。
じゃ、開き直って、人に見せないと決めてしまえば、作りは雑になりますよね。（マジメな人が作ればそんな事は無いのでしょうが…）雑ならば運用も自分でやるハメになります。実はそういう運用なんかも嫌だったりします。当然（？）後輩に押し付ける事になるのですが、恨まれます。それはそれで困りますよね。
それに、SQLが使えない環境だって在り得るわけです。（そこまで行くとかなりのトホホ環境でありますが…）
これはテキストベースの誰でも使えるようなPHP掲示板がが必要と言えるのではないでしょうか！？

とりあえず奮起してみました。

■仕様について
tak-yさん仕様をこちらで解釈した事を書き上げるとこういうことかな…と思います。

Patioなど上げられている掲示板の特徴を考えると…
・スレッド型でアイコンが付くような掲示板
・パスワードを設定して書き込み者の自由で書き込み変更が出来る
・IP規制が出来る
・トリップが付けられる
・過去ログを勝手に纏めてくれる

加えてtak-yさんや、その他皆様が仰る事を考えてみると…
・管理画面がGUI
・基本的にデーターベースを使用しない（以下と矛盾するかもしれませんが…）
・携帯用のページも吐き出したい
・サブ保存形式はXML（独自だとするとdtd書くのカナ；；）
・サブ保存形式はSQLite（私には分かりません；；）
・サブ保存形式はMySQL

個人的に入れたい機能として
・RSSを吐き出したい
・検索も付けたい
・スラッシュドットのように敷居幅をつけたい
・ツリー表示もやっぱりほしい

こんなところでしょうか。
足りないようであれば加えてください。削るのも大歓迎です（ぇ

[18] mixiユーザー 08月27日 02:13

だんだんおおごとに・・・わはは。面白いなあ。

SQLite、どうということないです。
使い方はMySQLとかPostgreSQLとかと変わらないです。
サーバがいらなくて、単一のファイルに保存されるだけです。
http://jp.php.net/manual/ja/ref.sqlite.php

PHP5からはSQLiteが同梱され、
明示的に削除しない限り勝手にコンパイルされます。
PHP4系列は・・・どうでしょう？

-----
DBを使わない場合の話、
・「<>」で区切るのはやだなあ。ーー;)
・毎回全ファイル書き換えは勘弁して欲しい。
　重いし、ごく稀に、ぜんぶ消えますから。

-----
個人的希望。
贅沢ばかり言ってますので、
テキトウに間引いてください。

・削除は、削除マークをつけるだけ。
・パスワードは生で保存しない。
・データファイルを、カレント以外に置ける。
・メールアドレスを表示する場合、スパム対策。
・ユーザ認証。書き込みのパスワードとの統合。
・ユーザごとの権限管理。管理者書き込みの識別。
・クッキー貼り付けによる利用者識別と規制
・ウェブベースのインストーラ♪

荒らしの規制は、こんなのどうですか？
IPかクッキーで規制中のユーザは、書き込みはできるけれど、
その書き込みを普通のユーザに見せない。
実際に実装したことがあるんですが、
トラブルがすぐに沈静化します。

[19] mixiユーザー 08月27日 02:44

なんか、しばらくみない間にこんなにレスがついていたとは！

えっと、まず自分でつくっちゃえば、というご意見をいただきましたが、スレッド型掲示板クラスのスクリプトをゼロから組めるほどのスキルは残念ながらまだありません。。初心者に毛が生えた程度のものです。。
それと、なぜDBではなくテキストベースなのかといえば、使っているサーバではPHPは使えてもDBが使えないのです。。（とほほ。。
というわけで、例に挙げたようなものを考えていたのです。

自分の理想的な物に近いといえば、WhiteWingさんが挙げたclreaは割といい感じです。レッツPHP！のサイトにあるスクリプトはだいぶいじくり回してみましたが、やはりちょっと違う感じでして。。

コミュでの開発、これは確かに面白そうですね。
個人的にこれは絶対欲しい仕様のようなものを挙げさせてもらうと
・必要最小限の機能で動くシンプルな設計
・DBは使用しない（xml等でデータ保存）
・スレッドを自由にたてられてレスできる掲示板（アイコン等は不要かな）
・基本的にトピックを一覧で表示する（ツリー表示ではなく）
・スレッドにレスがつくと上がる
・ユーザは自分の書き込みを削除や編集できる
・文字コードはUTF-8がよさそう
・RSS吐き出せるとうれしい
・過去ログ機能

ツリー表示などその他の機能はモジュールのような形で拡張していけるような仕様だと便利じゃないかなと。

いかがでしょうか。

[20] mixiユーザー 08月27日 09:34

■基本コンセプト
・必要最小限の機能で動くシンプルな設計

===
■外部仕様案

・スレッド型が基本で他（ツリーや新着のみ、携帯電話用など）は拡張可能な表示
>>どうやってやるか…な。ブログの管理画面でプラグインを増やすようなそんな形で出来たらいいですね。

・スレッドにレスがつくと上がる（スレッド型仕様）

・管理画面がGUI
・基本的にデーターベースを使用しない
・携帯用のページも吐き出したい
・サブ保存形式はXML（独自だとするとdtd書くのカナ；；）
・サブ保存形式はMySQL
・サブ保存形式はSQLite
>>理解できました＾＾非常に便利そうですが便利すぎてこれをベースで作ってしまいそうです。そうすると基本コンセプトから外れてしまいそうです。
>>高速モードとしてSQLiteでの書き込みモード、MySQLでの書き込みモードを用意しましょう。正直XMLは避けたいです；；

・過去ログ現行ログの串刺し検索を付ける
・スラッシュドットのように敷居幅をつけたい

・削除は、削除マークをつけるだけ。
・パスワードは生で保存しない。
・データファイルを、カレント以外に置ける
・メールアドレスを表示する場合、スパム対策
>>スパムリストを作って非表示にする等
・ユーザ認証。書き込みのパスワードとの統合
>>ゲストモードと固定ユーザモードと管理人モードなどを作りましょうか？
・クッキー貼り付けによる利用者識別と規制（？）
・ウェブベースのインストーラー
>>チョイト難しいかも...でも便利かな。

・RSS吐き出す
・過去ログ機能
>>過去ログを勝手に纏めてくれると言う事以外に検索…あとは何でしょうか？過去ログは一般ユーザからは編集不可ということでいいと思います。

■内部仕様案

・文字コードはUTF-8がよさそう
・文字コードはSJISがよさそう
・文字コードはEUCがよさそう

■製作スケジュール
９月初旬までに外部、内部仕様作成
各画面のスクリーンショットも９月中旬に完成
１０月初旬に製作者の割り振り、担当するモジュールとのインターフェイス決定
１０月中旬に実際の製作をはじめる

と言うカンジで＾＾
仕事じゃないのでちょっとマッタリペースですが、いかがでしょ

[21] mixiユーザー 08月27日 09:50

コミュでの開発、面白そうですね。
便乗すると、掲示板デザインはcssで記述可能にして自由度の高いデザインができればいいかな、と思います。

また、「必要最小限の機能で動くシンプルな設計」ということでプログラム本体は書き込み・観覧をサポートするくらいにして、その他の機能はすべてプラグインで機能拡張可能にするというのもいいかな、と思います。ブログでいうとblosxomみたいなイメージでしょうか。

[22] mixiユーザー 08月27日 10:45

＞さまよえるプログラマさん

>>PHP
でも、よく考えたら今のメインストリームはまだまだPHP4なので実際のところはSQLiteはオプション的な実装がいいかもしれません。

>>HTML
あと、Smartyなど使ってデザインとプログラムは切り離した方がいいかと。そうすれば、UserAgentによって読み込むテンプレートを変えれば携帯対応も難なくいけると思います。
更にcss使う方向で。

>>保存形式
データベースが無理。SQLiteも無理と考えるとテキスト保存しかありませんねぇ…。
自分はタブ区切りテキストをよく使ってますがどうでしょう？
正直XMLは可能と言えば可能ですが、あまりやりたくはないですねぇ…
でも、テキスト保存でスレッド型だとclreaみたいにスレッド毎にログを出して吐き出さないと走査に時間がかかりそうです。

>>スパムリスト
面白そうかもしれませんね。ところで、/.型のモデレートってどうする方向ですか？

>>ウェブベースインストーラー
これはどっちかと言うと表示させるHTMLを作るほうが手間がかかります、はい。
複数ページにわたるならセッションでデータ引渡しですかねぇ…

>>RSS
PEAR:XML_Serializerとか使うと一気に吐き出せるかも
http://ns1.php.gr.jp/pipermail/php-users/2004-December/024339.html
↑色々問題ありそうですが…

>>過去ログ機能
過去ログはHTMLをベタに吐き出す方向ですか？
管理者が編集可能とするならHTML吐き出しはまずいですね。

>>ユーザー認証
何かまんまphpBB…（笑

>>文字コード
UTF-8推進で（ぉ

>>スケジュール
まぁ、またーり進行で行きましょう

＞たかおんさん
プラグイン拡張ですかぁ…。でも、少々やりすぎな気もしなくはないです（ぉ

[23] mixiユーザー 08月27日 12:48

書いたら書きっぱなし、時刻昇順表示で良いのならテキストファイルにどんどんappendしていく方法が高速で堅牢ですよね。ファイルロックは意外に面倒だったりしますし。ただ拡張性はなくなりますね。

その場合レコードセパレータは普通にタブ文字でいいんじゃないかと思います。文字コードはShift_JISだと環境によって「十」とかの2バイト目の扱いが違ったりするのでちょっと面倒かも。

あと、叩き出した仕様で満足するのか、この先どんどん拡張していくのかによって設計も変わってきますよね。

[24] mixiユーザー 08月27日 12:48

HTML、CSS部分のデザインについては微力ながらお力添えできるかもしれません。

対応ブラウザとHTMLはどのようになるんでしょうか？

他の部分は見学させていただこうと思います。
PHPに関しては足手まといになってしまうかもしれませんので。

[25] mixiユーザー 08月27日 14:28

>たかおんさん
ブログのようなシステムがいいですよね。私もそういう風なカンジを考えております。
出来ればスクリーンショットを作ってみていただけませんか？＾＾私も作ってみますので＾＾

>WhiteWing さん
SmartyにSQLite…私の知らない事が多いので楽しそうです。
勉強もさぞかし乗り越えると楽しくていいのだろうなぁ…と妄想が広がります。今のうちに勉強してしまいます。
保存形式はどうしましょうかね…まだ意見が少ないので…
XMLでもPEARを使えば結構簡単にいけますからその辺は心配ないと思います。
また、スレッド形式でも実際のログデーターはタブ区切りテキストでもいいかな…と。でも下まで読むので走査に時間がかかるというのはごもっとも。サーバー負荷も考えると複数ファイルに分けてシェアする仕組みを作るとか…うむむむ楽しそうです。
スラッシュドットの敷居は一応後回しです。知らない人には不便な機能だと同僚に指摘されました。今回のコンセプトからも外れると判断いたしました。
インストーラーや、コンソールなどはセッションでもPOSTでもその辺りは適当でいいと思います。複数ユーザーで触るところではありませんからそれこそ何でもよいかと。（ぇ
RSSの引き出しはPEARに任せようと思います。自分で作ると考えると若干おっくうです。確かにマルチバイト関連で痛いバグがあったように思います。
過去ログはベタHTMLではとってもまずいので、暗号化したテキストファイルで行きましょう。
検索に使われないほどの過去ログの場合はZIPで圧縮してしまおうとかも考えております。この辺りはやった事があるので大丈夫です＾＾ノ
phpBB…えっとそんなもの知りません知りませんｗ良いものはパク…いえ…いえ。

>かなださん
結構な拡張性を想定しているのかもしれません。この開発。
挫折したらたたき出し仕様で…（ぇえええ

>vis（y_eii）さん
デザインはいくつか作りたいですね～スクリーンショットを作っていただけると、具体性が増します＾＾もしお時間があるときに作れましたらアップしてみてください。

内部仕様を考えていくと、楽しくて寝られなくなりますので、まず外見を決めて行きませんか？＾＾
私、外部も内部も一緒に考えてゆくと妄想のままで何も出来なくなりそうです。
内部仕様はとりあえず文字コードくらいで＾＾
UTF-8…というかそれに決めてしまいましょう。
SJISだけは勘弁していただきたかったので他であれば何でもOKかと思います。

あれれ私が仕切ってしまっているような；；だ、だれか代わってください。

[26] mixiユーザー 08月27日 19:20

開発に参加するメンバー数等も分かるのでイベント記事としてトピックを立てさせてもらいました。

よかったら下記にて参加表明お願いしまーっす＾＾

http://mixi.jp/view_event.pl?&id=1869178

[27] mixiユーザー 08月27日 19:46

流れはやいですねぇー

＞かなださん
仕様については柔軟性を持たさないと駄目ですね。

＞vis（y_eii）さん
デザインできる人は貴重です。
いやはや、自分でHTML書くと本当にシンプルになってしまって、味気なくなるもので…
対応ブラウザは、IE,FireFox,携帯ブラウザ(HDML,XHTML,HTML)と言うところですかねぇ…
しかし、携帯ブラウザの面倒を見るとなると結構面倒そうな気も…
ちなみに、携帯ブラウザを考慮する場合は出力文字コードは携帯ブラウザ向けのみShift-JIS固定じゃないと駄目です。
PC向けはXHTML 1.0 TransitionalかXHTML 1.1ですかねぇ…

＞さまよえるプログラマさん

>>Smarty
場合によってはオーバーヘッドになりますが、ロジックが切り離せるのがやっぱり利点です。
テンプレートファイルの中にもロジック書けちゃったりしますがｗ

>>ログ
やっぱり、タブ区切りテキストが現実的ですね。
ところで、過去ログの暗号化って必要ですか？
普通に管理者以外から何も出来ないようにすれば十分かと。
読み出すときの復号化も意外とやっかいかと。
あとはZIP圧縮というかzlibで圧縮ですか？zlibはオプション指定されて無いと使えない諸刃の刃、素人には（ｒｙ

>>内部仕様
まず、どんなPHPで走らすかを想定すると出来る事と出来ないことが見えてくるのでそこからかなぁと

PHP4.1.0以上
mbstring使用可能

ぐらいで見ておくといいのかもしれません。
場合によってはPHP4.2.3以上でもいいのかも

PHP5にもすんなり移行できるように書いておくと吉ですね。

>>文字コード
異議なしｗ

とりあえず、この手のことは言いだしっぺの人ががんばるものなので（ぉ
PM頑張って下さい（何

[28] mixiユーザー 08月28日 12:44

何やら参加者が11人になってましたね。
イベントトピで出てたものとしてはmojaviとかありましたね。

http://iteman.typepad.jp/blog/files/hustling-mojavi.html
http://www.stackasterisk.jp/tech/php/mojavi01_01.jsp

慣れてないとこの辺は厳しいかもしれませんね。
とりあえず、内部仕様は放っておいて外部仕様を決める方針ならこの辺の事に関しては後回しにしてもいいかもしれません。
しかし、mojaviは未だに使いこなせてません…。

ところで、sourceforge.jpのプロジェクト申請しちゃいますか？（早
あとはIRCとかで連絡取れるようにしたほうがいいかもしれませんね。
チャンネル名は#mixiforumとか#mixibbsあたりですかね。

[29] mixiユーザー 08月28日 13:57

とりあえず作ってみました。
XHTML 1.0 Transitionalに準拠させているつもりです。
実際の横幅は760pxとなっています。
携帯向けのは作ったことが無いので不安ですね・・・。

恥ずかしい限りですが、画像で不十分かもしれませんので
http://www.geocities.jp/dennou84/design/prebbs.html
に置いておきます。文字コードはshift_jisです。
クラス名も適当ですので、こちらの方が分かりやすいというものがございましたらお知らせください。

その他、何か改善点がございましたらご指摘ください。

[30] mixiユーザー 08月28日 14:19

>vis（y_eii）さん
仕事が速いですね～＞＜
クラス名などは後で決めていきましょう。…ということはCSSもしっかり設定済みなのですね＞＜素晴らしい。
早く私も作らねば…。
私は普段イラストレーターで書いてからDreamWeaverあるいは秀丸でコーディングする形を取ってます。
なので、ココにはスクリーンショットのみを載せる予定です。月曜日の夜アップ予定…。早ければ今日、掃除が終わりましたら作ります。

[31] mixiユーザー 08月28日 19:55

＞vis（y_eii）さん
お仕事速くて頭が上がりません。
普段、デザインはデザイナーさんに投げてしまっているので色々勉強になります。
ちっとはデザインの勉強もしないとなぁと思います。

＞さまよえるプログラマさん
期待して待っておきますね（ぉ

そういえば、まだ名前が決まってませんよね。
そんな訳でフォーラムの名付け親募集。

[32] mixiユーザー 08月28日 21:26

MixiBS（ミービーエス）なんてどうでしょ＾＾
BBSとMixiをくっ付けた造語です。長いのは嫌ですよね～

http://www.sf.airnet.ne.jp/~ts/language/numberj.html

この辺りを利用してカッコイイ名前をつけるというのもよろしいかと＾＾

[33] mixiユーザー 08月28日 21:55

盛り上がってますねー。
流れ早すぎ。

内部コードSJISだけはご勘弁を。
EUCか、イマドキならUTF-8で。

逆に外部コードはEUCだけはご勘弁を。
SJISか、イマドキならUTF-8で。

「過去ログ」って違和感あるんです。1000になろうが、10000になろうが、100000になろうが、そのままほっといて閲覧できるようにしたいです。

さっき、イベントの方にも書いたのですが、携帯とPCとで画面遷移を同じにできない可能性があるので、テンプレートで表示だけ変えようってのはうまくない気がします。あるいは、携帯とPCとで別扱いにするか。

日本語以外への対応の余地を残したいです。プログラム中にいきなりmb_系の関数が入ってると、他の国では使いづらいですよね。

ストレージは、基本はテキストでしょうね。でっかい単一のテキストファイルにアペンドしまくり＋インデックスファイルって、わりかしうまくいきますよ。削除は、ファイル中でseekして、フラグを書き込むだけ。記事の編集は、削除＋新規でごまかす。ディスク容量は気にしない。管理画面に、過去記事・削除済み記事の本当の削除、インデックスの再構築、などの機能が必要です。

ライセンスどうしましょうか？
GPL？

[34] mixiユーザー 08月28日 23:09

むむむ…段々シンプルではなくなっているような気がしますが、がんばりましょう。
内部コードはUTF-8でほぼ決定ですね～内部外部統一で外部もUTF-8で行きたい…ですね。
しかし携帯用の掲示板に関しては、SJIS出力も準備した方が良さそうです。確かボーダーフォンはSJISでしか見れなかったような．．。（？）
外部はSJISが安全かもしれません。

md系の関数なしと言うのは厳しくないですか？（弱気）
私は日本語以外への対応の余地はなくてもいいかなぁと思います。
多言語対応は今回のコンセプトからは外れるかもしれません。
皆様のご意見をお待ちしております。

ファイルへのアクセスに関してはもう少ししてから論じましょ～
せめて外部デザインが決まってからの方がスンナリ行くかと思います。
みんなで眠れなくなりますので＾＾；
ではチョイト整理します。

■基本コンセプト
・必要最小限の機能で動くシンプルな設計

■外部仕様案

・スレッド型が基本で他（ツリーや新着のみ、携帯電話用など）は拡張可能な表示
・スレッドにレスがつくと上がる（スレッド型仕様）
・管理画面がGUI
・基本的にデーターベースを使用しないテキストファイル

○携帯専用のページを吐き出す
○携帯専用は作らずレイアウト変更だけでナントカ対応

○メイン保存形式はXML
○メイン保存形式はCSV
○メイン保存形式はタブ区切りテキストなど何らかのセレクターを利用するテキストファイル

○サブ保存形式はXML（独自だとするとdtd書くのカナ；；）
○サブ保存形式はMySQL
○サブ保存形式はSQLite

○過去ログ現行ログの串刺し検索を付ける
○過去ログという考え方をなくして一本のファイルに検索をかける

・削除は、削除マークをつけるだけ。
・パスワードは生で保存しない。
・データファイルを、カレント以外に置ける
・メールアドレスを表示する場合、スパム対策
○スパムメンバーリストを作って非表示にする
○メールアドレスは表示させない。特定の人数しか入れないチャット部屋もどきを準備。入室の際になんらかの名前を入力させ、特定人数以上入れないようにしておく。（まだ考え中…

・ユーザ認証。書き込みのパスワードとの統合
・ゲストモードと固定ユーザモードと管理人モードなどを作る
・クッキー貼り付けによる利用者識別と規制（？）
・ウェブベースのインストーラー

・RSS吐き出す

○過去ログ機能あり
○過去ログ機能なし

■内部仕様案

・文字コードはUTF-8がよさそう

○mbstring系を主に利用
○mbstring系は使わない

○巨大テキストファイルにアペンドアクセス
○複数ファイルにアクセス

■ライセンス

○GPL
○完全フリー改変OK

■製作スケジュール
９月初旬までに外部、内部仕様作成
各画面のスクリーンショットも９月中旬に完成
１０月初旬に製作者の割り振り、担当するモジュールとのインターフェイス決定
１０月中旬に実際の製作をはじめる

膨れ上がる風船は飛行船になるかな？＾＾
付属した画像は作り途中のスクリーンショットです。

[35] mixiユーザー 08月29日 00:47

>>さまよえるプログラマさん
内部コードをUTF-8でPCも携帯も出力はSJISでよくないすか？

[36] mixiユーザー 08月29日 00:55

＞かねさん

>>文字コード
基本はUTF-8で。携帯はSJISでといった感でいいかと。

>>携帯向け
これはある程度形が出来上がってから後付でもいいかもしれませんね。

>>mbstring
国内使用に限定してもいいかもしれません。
しかし、mbstringモジュールが使えないこともあるのでjcode.phpで対応するという方向がいいかと思います。

>>ストレージ
基本は外部仕様ができてからって事で。
まぁ、タブ区切りテキストはほぼ確定で。

>>ライセンス
ライセンスは組み込むライブラリにもよると思うので要検討事項だと思います。

＞さまよえるプログラマさん

>>MixiBS（ミービーエス）
それくらいシンプルでいいかもしれませんね。
コンセプトが分かりやすいのがいいと思います。

>>SS
MacOS X風デザインってさまになりますよね？（ぉ
閉じたり開いたりって事は流行のAjaxですか？

>>膨れ上がる風船は飛行船になるかな？＾＾
何か適当に妄想しておけばできそうな気が（ぉ

使えそうなライブラリ一覧(忘備録的)
//テンプレートエンジン
・Smarty
http://smart.php.net/
http://sunset.freespace.jp/smarty/
・HTMLテンプレートクラス
http://hoover.ktplan.ne.jp/kaihatsu/php/
・PHP4テンプレートクラスライブラリ改
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/links/links_0.7/system/tmpl2.class.php
http://ns1.php.gr.jp/pipermail/php-users/2005-February/025078.html
(こんなところで自分のプロジェクトに飛ばされてたとは…ｗ)
(いや、プロジェクト自体は大昔に書いた奴だからソースコード滅茶苦茶ですが。ちなみに、オリジナルのアーカイブもあります。)

//PHPフレームワーク
・Mojavi
http://www.mojavi.org/
http://www.stackasterisk.jp/tech/php/mojavi01_01.jsp
http://iteman.typepad.jp/blog/files/hustling-mojavi.html
・Agavi(for PHP5)
http://agavi.jp/
・Maple
http://kunit.jp/maple/
・Ethna
http://ethna.jp/
・grusswork
http://classic.guesswork.jp/

//文字コード
・jcode.php
http://classic.guesswork.jp/

//PEAR系
・PEAR:Auth
http://pear.php.net/package/Auth
・PEAR:HTML_AJAX
http://pear.php.net/package/HTML_AJAX
・PEAR:HTML_QuickForm
http://pear.php.net/package/HTML_QuickForm
・PEAR:Pager
http://pear.php.net/package/Pager
・PEAR:XML_Parser
http://pear.php.net/package/XML_Parser
・PEAR:XML_Serializer
http://pear.php.net/package/XML_Serializer

とりあえず、こんなところで。

[37] mixiユーザー 08月29日 01:56

そろそろ、
プロジェクトリーダーを決めた方がいいですね。
議論を仕切るひと。
どなたかー？

■文字コード
内部：UTF-8、外部PC：UTF-8、外部携帯：SJIS
ってとこでしょうか。

ん。内部をUTF-8にしたとして、
携帯の絵文字はどうなるのだろう？＞詳しいひと！

■多言語対応のはなし。
jcode.phpは想定してはいなかったのです。
単に、日本語依存の部分は別ファイルにできるといいなあと。

■ストレージに関して。
タブ区切りとかの「区切り系」は拡張性が低いです。
区切り系だと、項目の順番で識別するわけですよね。
誰かが何か機能を増やすために保存すべき項目を増やすと、
その順番がひとつ消費される。複数の人が増やした機能は、
同じ順番を使ってしまう恐れが高いから、
それら機能のマージは大変です。
あるいは、機能のプラグイン化も難しいです。

面倒だし、冗長に見えますが、
「email=xxxx」というふうな型と値のペアにするか、
PHPのserialize()を使うようにしたほうがいいと思います。
ディスク容量を気にするなら、gzcompress()で圧縮しちゃう。

まあ、ストレージのAPI（class定義）さえきっちり決めてしまえば、ファイル形式はどうでもいいんですけどね。

■ライブラリについて
非標準のライブラリは、慎重に。
僕らの書いた部分よりライブラリが大きかったら恥ずかしい！
ライセンスもめんどいし。

■名前
名前は・・・もう少し考えましょうよー。
イーマーキュリーが作ったと思われても困るし。
あとでいいんですけど。

まあ、最初はシンプルに。
勝手な印象では、最初は1000行くらいかなー（携帯除く）。

[38] mixiユーザー 08月29日 08:51

流れがはやい～

追い付くのに必至です・・・。

[39] mixiユーザー 08月29日 09:15

入出力ですが、携帯は入力もシフトJISになり得ますよね？

で、絵文字は確かJISの未定義領域に突っ込まれてたと思うので、そのままUTF-8に変換させるとUCS2の位置が決まらず変換ライブラリによって変換結果が不定になるような気がします。UTF-8に変換する前にUAを見て携帯キャリアごとに実態参照のようなメタ文字の形にしておいた方が良いと思います。

記録方式に関しては、タブ区切りでやっておいて依存性の吸収と拡張性はクラスに押し付けるという形ではダメでしょうか？MIMEのような形にすると性能が極度に落ちそうですし、シリアライズや圧縮させるとログの可読性がなくなりますよね。そこまでするならいっそRDB使う方が良いんではないかと思います。

ライブラリに関しては、smarty+mojavi+QuickFormでやるとライブラリのコードの方が圧倒的に大きくなると思います。あれやこれやインストールしないと使えないのはユーザにも不親切なので、この辺も独自に面倒みるのも面白いかも知れません。

ライセンスはGPLでいいんじゃないでしょうか？GPLでもフリーかつ改変自由ってのは保障されますし。

[40] mixiユーザー 08月29日 09:43

タブ区切りの場合、考えられる限りのカラムを用意しておいた上で、ユーザ拡張用のカラムを設けておくのも手かも知れません。例えば、

名前\tメールアドレス\t内容\t日付\t削除\taaa=bb&ccc=dd&eee=fff←ココ

のような感じで、1つのカラムにだけ複数の情報が突っ込めるようにしておく。拡張機能を使わない限りその部分は空文字列なのでパースせず性能には影響が出ない。タイトル一覧、本文検索などの場合もその部分をパースしないようにすれば、普通のタブ区切り形式と同等の性能が保証される。落しどころとしては悪くないと思うのですがどうでしょうか？

[41] mixiユーザー 08月29日 09:47

「CSVの1行目はカラム名」という制限をつけておくと比較的自由になるかもしれません

[42] mixiユーザー 08月29日 10:09

な、流れが速いですね(苦笑

流れが速いのと、人が増えてきたので仕切る人がいないとせっかく盛り上がった話なのにまとまらなくなりそうですね....。
誰かいませんかねぇ？

とりあえず、名前に関してはmixiの「アンケート」機能を使用して名前を公募＆決めたらどうでしょう？（申し訳ないのですが、私はプレミアム会員ではないので立てられません....）
名前が決定したらSourceForge.jpでプロジェクトを登録して開発開始しましょう。

「フリーの掲示板スクリプトを探しています。」というトピック名だとわかりにくいので開発専用のトピック立てませんか？もしくは、掲示板開発に興味のないコミュ参加者の為に専用コミュニティを立てたほうがいいのかもしれません。

あとはWhiteWingさんがおっしゃっていたようにircで連絡取れるようにしたほうがいいかもしれません。＜ircなんて7年くらい使ってないよ･･･
まぁメッセンジャーでもいいかもしれません。

[43] mixiユーザー 08月29日 10:36

流れ、速いです。。w
ぎりぎり追いつくのがやっとって感じで。
なんか、みなさん、ものすごい勢いであれよあれよと言う間にいろいろ仕様の案が出てきてますね。ふと何気なく聞いてみたことがこんなことになって、嬉しいやら、なんとなく寂しいやら。w

日本のphp史に残るようなw素晴らしい掲示板スクリプトが出来たらいいな。なんて。

[44] mixiユーザー 08月29日 11:36

休日でしたから＾＾；ついつい書き込んでしまいました。
あとは仕事時間を削らない程度に妄想して、家に帰って実践と行きましょう。ほんとコーディングしたいけど我慢我慢…。Ｍｉｘｉも開き過ぎないようにしなければ…。

プロジェクトリーダーなんですけど、推薦という形で決めてはどうでしょうか？

加えて、アプリケーションインターフェースだけ決めて
内部仕様と外部仕様でリーダーを分けた方がいいと思います。
外部仕様に関しては携帯用、その他ブラウザ用と分けるのもアリかと。

肝心のＡＰＩ決定権は内部仕様リーダーが持つか、
それとも恐怖の営業が神様スタイル…外部仕様が持つか…

トピック立てはリーダーが決まった時にしませんか？＾＾

[45] mixiユーザー 08月29日 13:37

卒業研究が進まないんでつい（ぁ

まぁ、とりあえずIRCで色々話しませんか？
メッセンジャーだと確実に6人以上になりそうなのでIRCって提案しました。

[46] mixiユーザー 08月29日 13:56

デザイン部分は一応煮詰まりつつありますのでご報告を
BBSの名前は便宜上mixiBBSとしてあります。

とりあえずデザイン部分はここにおいておきます。
http://www.geocities.jp/dennou84/design/mixiBBS/menu.html

ご意見がある場合はお知らせください。

[47] mixiユーザー 08月29日 14:15

とりあえずircに参加できる人で話してみましょうか？
チャンネル名は「#mixibbs」で。

[48] mixiユーザー 08月29日 15:54

掲示板作成の話題ですが、専用のコミュニティを作成しましたので今後はそちらでお願いします。

http://mixi.jp/view_community.pl?id=290496

ログインすると、残り9件のコメントが見れるよ

最初
全て
最新の40件

前

1
2

Let's PHPコミュのフリーの掲示板スクリプトを探しています。

Let's PHP 更新情報

最新のトピック

最新のイベント

最新のアンケート

Let's PHPのメンバーはこんなコミュニティにも参加しています