id:Voluntas さんが memcached-client for Erlang のレビューをしてくれた

erlang

拙作の memcached client for Erlangを id:Voluntas さんがレビューしてくださった。
id:Voluntas さんは自分よりはるかに Erlang 力が上なので、より Erlang らしい運用しやすさを目指した視点が印象的。

変更点は memcached-client を改悪してみた - Twisted Mind にまとめていただいているので、ここでは変更の意図を読み、疑問点をまとめてみよう。

変更の意図

  • ただの gen_server だったライブラリを application とした
    • application が supervisor を起動する OTP スタイル。
    • simple_one_for_one でコネクションが監視されるのが魅力的。

疑問点

application 化にはどのような意味があるだろうか。supervisor で管理する事は直感的に正しいと思う。
ただし application は文字通りアプリケーションなのでライブラリ用途としての memcached クライアントにはなじまないのかもしれない。（Erlang application の意図を正しく理解できているか怪しいですが）

application 化することのメリット

  • アプリケーション固有の設定を app ファイルに指定しアプリケーションとして扱う事が出来る。例えば自作 KVS はコマンドラインアプリケーションにしている。
  • 起動が application:start に簡約化されるのでユーザーが使いやすい
  • supervisor を起動するようにも出来るので、プロセスツリーの把握がしやすく監視も楽。

application 化することでライブラリとしてなじまないかもしれない事。

  • application:start の明示的な呼び出しが必要になる。memcached:connect だけではだめ。

ライブラリのパス

application かどうかでライブラリとしてのパスは特に変わらない。

  • 適当に使うなら -pa ebin で
  • きちんと使うなら make install すればパスの通ったところにライブラリとしてインストールされる

整理

書き出してみると自分が分かっていないところが明確になってきた

  • Erlang の application とは何か。どのような場合にアプリケーションにすべきか。
  • memcached client のようなライブラリはどのような配布形態が望ましいか。
    • gen_server ?
    • application ?
    • supervisor + gen_server ?

アプリケーションのマニュアルの冒頭には

When we have written code implementing some specific functionality,
we might want to make the code into an application,
that is a component that can be started and stopped as a unit, and which can be re-used in other systems as well.

start/stop したいかどうか？が肝なのかもしれない。