Project Home Downloads Wiki Issues Source
ロードマップ  
ロードマップ
Updated Dec 17, 2012 by normalpe...@gmail.com

MogileFSのロードマップ

High level overview of future plans/ideas. There is no set schedule and everything listed here is up for debate, refinement, addition, or could be dropped.

フィードバックやここで見たいものがあれば、メーリングリストでスレッドを開始してください。

以下は順番に意味はなく、詳細の実装は欠けているかも知れません。

perlbal プラグインの完全な機能

MogileFSが順調なスタートを切るには難しそうです。まず、サーバシステムをセットアップし、アプリケーションをファイルの参照およびreporxyをするために調整する必要があります。A perlbal plugin should be provided with the distribution which is able to directly serve files itself.

動作するコードのレビューはメーリングリストにポストされています: http://groups.google.com/group/mogile/browse_thread/thread/e3a33161d2da1d2a/00889fe6893fab21

ドキュメントの改善

いくつかあるいは全てのwikiはコードのPOD ドキュメントに移動する必要があり、そしてwikiはそれから生成されます。あるいはせめてもっとドキュメント化されるべきです。

制御/監視のもっと広範囲に及ぶtracker

何度も何度も人々にtrackerにtelnetしてコマンドを実行するように言ってきました。代わりに、mogadm がジョブの制御、監視などの中心になれるようにすべきです。もっと多くのtrackerの設定がconfigファイルから引っ越してデータベースに入るべきです。

ファイルのチェックサム

この機能は2.60で実装され、後のリリースで洗練されました。チェックサムを見てください。

JSON プロトコルの整備

プロトコルは平坦でとても手がかかります。JSONにもとづいたプロトコルに置き換えることはプロトコルを処理するコードをとても単純にするでしょう。Many languages have JSON libraries available by default now, so it would also make it simpler to port.

リプリケーションの整備

リプリケーションは追跡可能である必要があり、もっと良い拡張APIを持っています。Currently "ran out of ideas for replicating blah" is often the most information you'll get.

システムのバックアップ/リプリケーションからの脱却

mogileが削除とアップロードを処理する方法に柔軟性を追加することは可能です。全ての変更は、S3などのバックアップシステムにリプリケートされるかも知れません。

ファイルのバージョン付け

全ての上書きされたファイルはヒストリーテーブルを使ってバージョンを付けられるべきです。Making it innately possible to undo deletes or seek around in history, useful for a backup system.

Comment by project member jon.skar...@gmail.com, May 16, 2011

これが楽観的な示唆であることは分かっていますが、pOSIX準拠のインタフェースを持つことはクールでしょう :)


Sign in to add a comment
Powered by Google Project Hosting
TOP
inserted by FC2 system