[caiman-discuss] DC checkpoints

[Jack Schwartz]

Hi Dave.

Thanks for your feedback.
>>
>>
>> 1) If we want to support multiple checkpoints from within a module, I 
>> suggest that the module itself posts the error messages then returns 
>> a failure code. The finalizer can be set up to stop on errors, in 
>> which case the DC can pick up control. The finalizer can be enhanced 
>> to return which script failed. It already returns the script's 
>> failure code.
>>
>
> Checkpoints aren't really about errors.  A checkpoint is merely a 
> saving of state at a particular point in time, and usually won't have 
> anything to do with an error.  It lets you start from a particular 
> point in time, examine intermediate states, etc.  We might also allow 
> for stops at a given checkpoint (in other words, a breakpoint).
OK.  Sounds like the finalizer will need to be enhanced to support 
this...  I'll come up with something to discuss at the next DC meeting.
>
>> 2) I suggest that checkpoint info go somewhere other than the 
>> manifest. The manifest is like a blueprint for construction. Once 
>> figured out, it is static. It can be replicated and reused. 
>> Checkpoint info is state and applies to one run only. Yes, one may 
>> use state info to tweek the manifest until it works, but I recommend 
>> not blending static and dynamic into one file.
>>
>
> I'd agree with this.
>
>> 3) From the DC architectural diagram (even before I modified it), I 
>> thought that the GUI was a standalone tool used to generate the 
>> manifest, kept separate from the DC proper (which created the images 
>> from it). 
>
> No, the GUI will certainly have the ability to run the construction, 
> show progress, etc.  How we do that is a design issue to work out, but 
> I'd view the DC as a core engine which can have multiple different 
> user interfaces on it.  We might go so far as to provide a web service 
> and corresponding interface to create a manifest and run it using our 
> high-powered infrastructure, as I mentioned in the meeting last week. 
> But assume there will be multiple user interfaces and design accordingly.
>
>> 4) If we decide that the DC proper does have a GUI for parts other 
>> than creating the manifest, then the finalizer could be enhanced to 
>> write stdout and stderr through a socket back to the GUI for display. 
>> (Currently the finalizer only provides routing of stdout and stderr 
>> to a file or the console.)
>>
>
> That may need some enhancement.
OK.  I'll look into this.  Probably better to wait for the dust to 
settle before I do any more finalizer coding though...

    Thanks,
    Jack