On 05/26/10 07:26 PM, jean.mccormack wrote: > On 05/26/10 12:22 PM, Darren Kenny wrote: >> On 05/26/10 07:12 PM, jean.mccormack wrote: >> >>> OK. So now how as a checkpoint do I get my information? I would like >>> something similar to what the DOC provided. >>> Some object that I define that will hold the information? That object >>> handle would then be passed to me? Does that >>> idea work with pause/resume? Any other thoughts? >>> >> I think that it would still be possible for the registration of the >> Checkpoint >> to provide information into the DOC, to provide arguments as you describe, >> but >> what I'm saying is that the Engine won't be relying on the data in there - in >> effect it would most likely clear it after doing a resume, although it would >> have to be the one to put the information in the DOC so that checkpoints >> themselves can find it. >> >> So we've in effect back to the notion of having a CheckpointData (or >> CheckpointArgs) object to contain these arguments - but this doesn't in >> anyway >> imply the order that the Engine would execute them. >> > > I think so. So we have this still (not meant to be valid xml): > > <checkpoint> > name > other args specific to the checkpoint. > </checkpoint> > > Each checkpoint would have one of these in the DOC and the checkpoints > know which one is theirs > via the name. Not really a change for me. >
After sending this e-mail it dawned on me that there isn't a real need for this to be stored in the DOC at all - the Manifest Parser, when loading the information from the manifest could just as easily just pass it when registering the checkpoint, and the engine would store it itself in this case, and pass it as an argument to the execute() method (maybe). This is something that I think we can discuss as part of the Engine design really, since it's kinda out of the scope of the DOC design itself - it's only a use-case for it, and I don't think it's effecting the design of the DOC in so much as it's effecting the design of the Engine... As such, I've taken this off-line to discuss as part of that design. Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
