Hi karen -
Thank you for the review. See my responses below.
ginnie
On 01/06/11 17:55, Karen Tung wrote:
Hi Ginnie,
Here are my comments on the updated spec:
Section 3.1:
-----------------
- 4th bullet: It's transfer "checkpoint", not "module". Furthermore,
not all the removal of files/directories done by the previous ICT are
moved to transfer checkpoint. I think it is more accurate to say
that those functionality will be incorporated into the installer
and other checkpoints.
ok. I'll update that.
- 6th bullet: It's confusing to me what you are trying to say here.
Are you saying that the engine stores tracebacks from checkpoints in
the error service. Therefore, if a checkpoint throws an exception,
the full traceback is saved by the engine, and it is available to the
the application.
What I was attempting to capture was that there is an error service
available. But it seems like, generally, we've been allowing the errors
to be managed by the engine, instead of managing them at the checkpoint
level. I'll clarify that.
Section 4.1:
-----------------
- Item 1 in the 4th paragraph: "Each checkpoint performs one
installation task".
This is what a "well-designed" checkpoint should do.
The engine doesn't enforce that.
ok.
- Nit: I think it will be easier to change the nested 1,2,3,4 into some
other
bullet pattern so it is easier for the reviewers to refer to the items.
Sure.
- Item 3 in the 4th paragraph: "....Registration includes arguments
that...".
This sentence doesn't sound right to me. I think it will be more clear
to say that if
a checkpoint requires arguments to initialize, those must be provided
during registration time.
ok. Thanks.
Section 5:
---------------
- General comment about all the different checkpoint classes:
We need more detail on the "execute()" function for each of the
checkpoints.
I think it should contain information on exactly what it does.
eg: call this command, copy/move/delete/modify this file/directory..etc..
It would also be useful to detail what value from the DOC it consumes
and/or
any system resource it uses..etc.. It would also be useful
to include information about what error/exception the execute() might
raise.
ok. I'll flesh that out a more.
- General comment about the cancel() function in the checkpoints. Unless
you are going to do something special there. I think it is save to say
that you don't need it, and the execute() function will check the
cancel flag periodically.
ok.
- Section 5.6:
* is this checkpoint only used by the Live CD?
* The description sentence is not complete.
I'll fix that.
Section 6.1.2:
- The syntax for eng.execute_checkpoint() is not correct here.
ok. I must have looked at the wrong thing.
Thanks,
--Karen
On 01/03/11 13:03, Ginnie Wray wrote:
Hi -
I've updated the design document for the ICT conversion.
The document is available here:
http://src.opensolaris.org/source/xref/caiman/caiman-docs/ICT/ict_conversion.pdf
Or can be downloaded and viewed from the caiman-docs repo.
Instructions here:
http://repo.opensolaris.org/info/repository.action?projectId=213&repositoryId=128
I've updated it to reflect the feedback I received.
Please provide comments by COB January 14, 2011.
Thanks,
ginnie
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
