Jubatusサーバとモジュール分離にあたっての作業洗い出し

20130416_OSS_refactor_jubajuba.md

Jubatusサーバとモジュール分離にあたっての作業洗い出し

• Jubatusにおける作業項目を洗い出す、ゴールを決める
• 選択肢を列挙しておく、可能なら設計選択における利点欠点の整理。MTGで選択する
• 複数人で並列作業できるとよい

背景・概要は以下を参照

告知・議論）0.4.3リリース後は、 サーバ部分とフレームワーク部分の分離を進めたい (@suma) https://github.com/jubatus/jubatus/wiki/Meeting:2013_04_15#discussion

サーバとJubatusのアルゴリズム部分と依存しているモジュールを分離する。 （仮）サーバから分離した側をcoreと呼ぶ。

選択・決定すべきこと

• サーバから分離した側をcoreと呼ぶ
• 名前coreでいいの？
• 他：
• 新しいディレクトリ構造どれにする？
• jubatus/ {src, server/src} … src以下にcoreの部分、serverへサーバを押し込む。
• jubatus/ {src, core/src} … src以下にサーバ依存コードを押し込む。アプリは現在と一緒の形。欠点：serverが種類増えるとsrc/直下だと厳しい。
• jubatus/{server,core}/src … server, coreにディレクトリを分離しちゃう
• 別けたcore, serverの名前空間
• jubatus::core, jubatus::server で良い？
• 別けたcore, serverの共有オブジェクトの命名規則
• server側の共有オブジェクトはjubaserv_??? などとprefixはjubaではなくjubaserv_を付ける
• core側は今まで通りの命名規則で juba??? となる
• 開発体制、作業の進め方（スケジュールの目安）は？
• 少人数でスタート（1〜2週間の完了を目処） → 片付いたら人海戦術
• 人海戦術 ： 最初から全員でやるには無理がある
• 他の案：
• すぐやる・完了しだいやる… の作業分類で良いか（下記）

すぐやる

• ディレクトリを完全に別ける

完了次第やる

• ディレクトリ別けた後の、それぞれでのモジュールのリファクタリング（出来そうな所があれば）

今はやらない、後ですぐやるかもしれない

• coreだけで配布できるようにwscriptを別ける、APIを整える（すぐできそうだが...）
• ついでにモジュールの名前空間・共有オブジェクトの名前の一貫性を持たせる
• → "アルゴリズムやストレージのモジュール、ディレクトリ構造・クラス名の見直しを行う(#311 @beam2d さんの提案の継続)" も含む

分離後のディレクトリ構成の変更（例、上に依存）

+ jubatus/waf
          wscript
          src/<dir>　# server、今まで通りに近い
          core/src/<dir> # jubatus/srcからモジュールに必要な部分だけ抜き出す、ディレクトリ名はサーバと一緒でも良い

作業

• サーバだけで必要としているもの・coreへ分離できるものを分離

• src以下をcore/srcなどへ全部コピー（上で決めたディレクトリ構造に依存します）、それぞれ不要なもの・依存関係の整理

• モジュール名が衝突しないように別ける

• 生成する共有オブジェクトの名前をjuba???からjubaserv???へ変える（例）

• 依存しているライブラリもjubaserv??? へ変える、coreの依存があれば依存関係に追加する

• jubatus/wscriptではcoreから先にビルドさせるようにする（subdirs = ['core', ..略]）

• それぞれの名前空間をjubatus::serverとjubatus::coreへ別ける

• ついでにリファクタリングしたほうがよいかもしれないところ。それぞれcoreよりもサーバ側に置くべきではないか？

• 各アルゴリズムのfactory method (#311

• fv_converter/converter_config.cpp (string -> JSON -> converter_configへの変換部分)

サーバとcoreの整理

いまのディレクトリ（モジュール）をどう持ってくるか列挙（例）です。

• サーバが保持するディレクトリ・モジュール

• ZK有効時にコンパイルされるコード（HAVE_ZOOKEEPER_H でifdefのある実装コード）。抽象化しているインタフェース部分はcoreに持たせる

• common/rpc server, rpc_mclient

• common サーバで必要なもののみ

• framework/mixer/の通信部分の実装

• cmd

• jubavisor

• server

• third_party

• coreで保持するディレクトリ・モジュール

• anomaly

• classifier

• common: coreで必要なもののみ。メモ mprpcのbyte_bufferはcoreで要る（msgpackのpack/unpackしている関係で）

• driver

• framework (server_helperやserver_utilのcppは除く)

• framework/mixable, mixer: インタフェースやテストなど

• fv_converter

• graph

• plugin

• recommender

• regression

• stat

• storage

作業内容については特にコメントはありません。
ちょっと深い構造になってしまいましたが、ディレクトリ構成案を提示させて頂きます。

 jubatus
  + src
  |   + jubatus
  |   |   + server  ... 通信関連
  |   |   + tools   ... ツール、コアツール(jubaconfig) は server か?
  |   |   + task    ... 機械学習
  |   + third_party ... 再配布する依存ライブラリ