仕様書（設計）への希望、要望を書いておきます。
実現性については全く判断ができませんので、参考として捉えてもらえればと思います。
拡張性の高さ
機能一覧をいろいろ書き出しましたが、現実的に全ての機能を
最初のバージョンから実装するのは非常に難しいと思います。
ですので、後から機能を追加する際に困らないようにしたいです。
また現在ある機能一覧以外にも新たなアイデアが出てくると思いますので
そういうケースにも対応できるような構成であればありがたいです。
外部の開発者が機能追加をしやすい構成
これも拡張性の高さと重なる部分かもしれませんが
このソフトウェアはソースを公開して、誰でも開発に参加できるようにしようと思っています。
有志の方が開発に参加する場合に、ソフトウェアの構成が難しく
理解するのに非常に時間がかかるといったことがないようにしたいです。
中央サーバが落ちた場合もプロジェクトの開発を継続できる
中央サーバが落ちたときも作業ができるような配慮。
PeerCastで言うと、KPやCPが落ちてしまった場合、チャンネル情報を取得する術がなくなります。
中央のサーバが落ちたから仕事ができないという状況では困るため
リーダー（サーバ）のIPを直接入力することで、アカウント機能は使用できないが
プロジェクトには参加することができる、などの緊急措置的な方法も取れるようにしたいです。
リーダー＝サーバ役なのか？
リーダーがいないとそのプロジェクトは全く進めることができないのか
リーダーがいない場合も、参加メンバーの誰かが代理でサーバ役を行うことで
プロジェクトを進めるようにはできないでしょうか。
また発案者のPCスペックが低いため、サーバ役を十分に行えない
といったこともあるかもしれません。その際にも対応できるようにしたいです。
シンプルなエディタとして使う場合、チャットソフトとして使う場合
このソフトウェアを開発用途で使用するだけではなく
単なるエディタとしても使用してもらえるようにしたいのです。
オフラインのエディタ用途として使用する場合、プロジェクト一覧やチャット機能は不要です。
不要な機能を読み込まないことで、起動時間の短縮や、動作の軽快さを確保できないでしょうか？
例えばPeer Officeの起動アイコンとは別に、エディタの起動アイコンを作り
それから起動した場合はシンプルなエディタとして動作するといった具合です。
C/S型 or P2P型？
現在は各プロジェクトの発案者、リーダーが主にサーバ役を果たす
クライアント・サーバ型としての開発がいいのではないかと思っているのですが
P2P型にも利点は多くあると感じており、どちらかに決定するにはまだ遠い状況です。
2009/5/14
現在、Hybrid P2P型での開発がやろうとしている方向性に近いのではないかと考えています。
セキュリティ、ポート開放について
ポート開放を必須にすると導入障壁が高くなります。
誰でも使ってもらえるソフトを目指しているため、設定はできるだけ簡単に済ませるようにしたいです。
セキュリティの設定にも段階を設け、イントラネット上、インターネット上
用途に応じて切り替えて使えるようにできればなと思っています。
またUPnPに対応してポート開放の手間を省けるようにしたいです。
仕様書の作成過程
一気に作ってもらって、後で修正などをお願いするのは申し訳ないため
段階的に開示していってもらう形で進めていきたいです。
例えばまず草案の時点で、複数の案があればそれを書き出してもらって
配信などで意見を聞きつつ詰めていければなと思っています。
そうすることで興味を持ってくれている人も、作成過程から仕様に対する共通認識を持てるので
段階的に進める方法を取るのがいいのではないかと考えています。
現時点の考えに基づく構造等のイメージ化
855 名前：名無しさん[sage] 投稿日：2009/05/11(月) 23:34:29
・他のコンポーネントに負荷をかけない通信の仕様
・サーバーソフトの仕様
・クライアントソフト本体の仕様
・ログインの仕様
とりあえずこの４つだな