Well, SoC's final deadline is a few days away, I really enjoyed
this time :). Let's talk about the status now:
Right now SCIRE's job subsystem is capable of create, distribute,
run and monitor a job created, both for a single and for multiple
clients. All this is also reflect on the UI code. Finally, all the
code can be tested directly from the UI and everything seems to work
(No bugs doesn't mean it's right, just that is doesn't have visible
bugs). The latest patch implements the monitoring UI, and gives
pretty usefull information about the job.
What is missing? Once a job is completed it could be marked
as finished, failed or cancelled. If the job is
non-recurring, there's no problem as all this just becames
historical information. But for recurring jobs is a different story
as it need to be re-schedule, isn't it?. For successfully finished
jobs si pretty straight forward to assume that they should be
rescheduled automatically. But for failed? or cancelled?. I'm very
lean towards the user-should-choose option; after all, he knows
better what to do for every situation, as it may depend on the
job. So the best decision is not to let somebody else do the
decision :). But you also need a good default, so I'll do this as
follow: if a job has been marked as failed, re-schedule it
automatically, but if is has been marked as cancelled, don't
do it. This implies that the job creation template should include an
option to modify this behavior. Also, the re-scheduling mechanism is
not that hard to implement, the problem lies on who should execute
it. The observer pattern should come to the rescue. Isn't it
wonderfull when you figure out something while writing a post? I
should blog more often :)
Owner login
