Takuro Ashie
ashie****@homa*****
2002年 6月 1日 (土) 12:40:39 JST
At Sat, 1 Jun 2002 10:07:09 +0900, Kenji Suzuki wrote: > > On Sat, 01 Jun 2002 07:32:36 +0900 > Takuro Ashie <ashie****@homa*****> wrote: > > > 足永です。 > > > > で、繰り返しを展開は、UI が担当するのがいいのではないかという > > > 話になりました。繰り返しを展開するクラスを使うのは UI だと。 > > > こうすると 予約DBS は、個別の「予約」だけ管理すればいいので、 > > > 処理が簡単になるという話です。 > > > > うーん，どうなんでしょう． > > 結局繰り返しを展開するクラスがあるのであれば，それがUI側にあっても > > DBS側にあっても大差ないように思うのですが． > > (実際にはUI側には必ず必要でしょうが) > > > 最終的には最初期の実装のように program_list ファイルは(将来一週間分の) > > 単なる予約のリストになったとして，予約を監視するループなりプロセスなり > > はこれを見て次の予約を判断するとします(緊急録画等に対応する為に若干の > > 変更は必要かもしれません)． > > > > では個々の番組を巡回して該当する予約を拾い出し，この program_list を生 > > 成するの誰かと言うと，やはりDBSの仕事とした方がスマートだと思います． > > スマートだと思う根拠はなんでしょうか? > > > (番組データ) <-- 番組DBS(=UI?) が管理 > ｜ > ｜<-- 予約の生成 誰がいつ行う? > ↓ > (予約データ) <-- 予約DBS が管理 > > > UI で処理というのは、予約の重複などエラーを即座にユーザに通知できる > という利点があります。 これは絶対に必要なので， >> (実際にはUI側には必ず必要でしょうが) と書きました． UI側でこの処理をするのにDBS側でまた同じ処理をするのは冗長ですが * UI側で「予約データ」を生成してしまうと，無限予約に対応できなくな る(一定期間ごとにユーザーがUI起動しなければいけない?) * 必ずUIを通さなければならないため，直接エディタで予約ファイルを 編集する余地が無くなる という事を考えて．こちらの方が「スマート」と表現しました． また，予約ミスの通知はメールで行えば良いかな? と考えていました． が，後で考え直してみると，後者はエディタで編集した後に予約データを生成す るコマンドを打てばよいだけですね． さらにたった今思いついたのですが，このコマンドを予約監視のループの中で 一定期間毎に実行するように設定できれば，無限予約にも対応できるのではな いかと思いました．
