In order to get closure on this issue, Darren, Sarah, Alok and myself
met to resolve the issues.
We discussed the need for the transfer module to be a class with
IPS/CPIO as sub-classes. The original reason was based upon the belief
that we had to register all checkpoints at the top when we wouldn't
necessarily know what type of transfer was desired. With some thought
and discussion is was decided that we didn't have to register everything
at the top so the app could, after user input, know what type of
transfer it wanted and register everything to come at that point. This
removes the create_transfer method and the transfer class.
We discussed where target information would go in the DOC.
The decision was that target discovery would place this object in the
DOC at a known place. If for some reason there is more than one target
discovery object, they will be stored in order.
We also discussed where the desired target to be instantiated object
would go, that was also decided to be at a known place in the DOC. If
for some reason there is more than one desired target object, the
objects will be stored in the order upon which they will be needed.
Then we talked more about the checkpoint specific information. The DOC
has an execution object which has checkpoint objects under it. Each
checkpoint will have such an object with checkpoint specific data within
it.
The client app will do the following:
- instantiate the appropriate target/transfer objects
- store the target/transfer objects at a known place
in the DOC *in order* of execution
- register the checkpoints
- execute the checkpoints.
- the completed flag will be set to True in each checkpoint that
has successfully executed.
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
