[ kuroko ] 仕様を考えてみる

backburnerやRUSHなどを見本に、
kurokoの仕様を考えてみます。

まず、命令を送るクライアント、受け取るサーバーが必要。
クライアントは送るサーバーを覚えてないといけなくて、サーバーは常に受け取れるようになっている必要がある。

でもサーバーはレンダリング中だったりするわけで、
状態を見てタスクを投げられるかどうかを判断する必要がある。

しかもクライアントはいろんなマシンで立ち上がったりする。
となると、サーバーの状態などを管理するもの、マネージャがあった方がスマート。

これはbackburnerやRUSHとほぼ同じ構成と思われる。
サーバー、マネージャ、クライアントという構成は
おそらくほとんどのレンダリング管理ソフトが採用しているのでは。

最も理にかなっていると言うか、一般的なんだというのはわかるけど、
それの仕様で良いんだったらkurokoを作る必要もないので、もうちょっと違うアプローチを考えてみる。

そもそもkurokoの目的は、空いているマシン数台を
一人で占拠してレンダリングを行いたい、という感じ。

サーバーマシンはマシン名をファイルに記述、っていう程度の簡単なものでOK。
ネットワーク上を探しに行くような本格仕様じゃなくて良いです。

クライアントも常に立ち上がってるんじゃ邪魔だし、間違って消しちゃうこともあると考えた場合、
クライアントは単純にタスクを投げるだけにさせた方が良い。

とするとサーバー側で状態管理、タスクのスタック、という処理を行うことになる。
途中でエラーが起きて落ちたらどうするか、という問題はある。

とするとやっぱりマネージャを介した中央管理型が一番安全、という結論になる。

でも、もしエラーで落ちてもOK気にすんな、ってことにしておけば
その辺無視してもいいじゃん、と考えることも可能。

もしくはエラーで落ちた時に復帰出来るように、
状態とタスクを外部ファイルに書き出しておくなどの対処もある。
クライアント側の入力を全部GUIから、ということにしなければ、
テキストベースでタスクリストを作るのだって比較的簡単に行えるはず。

うーん、だんだん見えてきた。

ちょっとまとめると、
・kurokoはクライアント、サーバーの2種類のアプリから成る。
・クライアントは単純なsubmitter。基本はGUIということにするが、CUIからの入力も可。
　→CUIからの入力を可能にすることによって、MELなどからのsubmitも可能。
・個々のサーバーがタスクの管理などをそれぞれ行う。
・サーバーが落ちたりした時用に、ある程度の復帰が出来る方法を用意する。
　→例えば外部ファイルにタスクリストを収めておくとか。

大体こんなもんかね？

僕の技術力で実現可能なもの、ある程度は実用的なもの、というところで
そこそこの落とし所を見つけたつもりですが、
ソフトウェア工学とかを学んだわけではないので、
もしかしたらシステム的に致命的な部分もあるかもしれません。

まぁそこは結局勉強よりも経験だろう、ということで、とりあえずはこんな感じで進めてみる予定。

なんか突っ込みなどあれば是非どしどしよろしくお願いします。

ちなみに現在の開発状況は0％ですｗｗｗ
公開目指して頑張りませう。