On 05/19/10 07:34 AM, Darren Kenny wrote:
Hi,
We would like to ask people to please review the Data Object Cache design
document, which can be found at:
http://hub.opensolaris.org/bin/download/Project+caiman/DataObjectCache/DataObjectCache%2DDesign%2D0.5.pdf
The Data Object Cache is will be part of the infrastructure for the installer
and your feedback will ensure that it will meet the needs of the consumers of
its API.
Thanks,
Darren and Dermot.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
Hi Darren and Dermot,
Very well written and thorough document. I have a few comments.
General comment:
--------------------------------
There's no discussion throughout the document on how any error from
interacting with the DOC will be reporting, ie: what kind of exception
will be raised..etc..
Also, there is no discussion in the document about what, if anything,
messages
will be logged to help with debugging..etc..
Specific comments:
---------------------------------
Page 4, section 1.1, 5th paragraph...
"....writing this to a permanent store such as a file is done by the
ManifestParser, but the DOC coordinates this process."
I understand you want to express the idea that DOC will not be writing
the XML manifest. However, I think it is confusing to specially call out
ManifestParser as the component that will do the work. To me,
the name ManifestParser suggests that it is the program that will
parse the manifest. It is confusing to say that a parser will write the
content too. Would it be better to mention that some other component will
write the XML?
page 9, section 3.4.1.1
The description of "parent" property says that it is a read-only property by
consumers. In the tree manipulation section,section 3.4.1.2, none of
the append child API allow you to specify a parent object. How do
I create the tree structure?
Page 9, section 3.4.1.2
I think it would be helpful to have some psedo-code somewhere creating
a tree with some fake objects using these APIs. I think that will
really help in understanding how these API can be used to build and
manipulate
the tree.
Page 24, Use Case #2
I am completely confused by this example, it seems to contradict
with the current engine design in quiet a few areas.
Below is my understanding of use case #2.
I want to make sure we are on the same page before I make further comments.
My understanding of use case #2 is that information about each of the
checkpoints the application wants to execute will be store in
ExecutionCheckpoints objects. The application will create these
objects and add them to the DOC.
When the application calls execute(), the engine search the DOC for
the list of un-executed ExecutionCheckpoint objects,
and initialize the checkpoints and execute them. Therefore, we will
*not* need to have the engine.register_checkpoing() functionality??
The application will register the checkpoints they want to execute into
the DOC directly, instead of going through the engine.
The above is my understanding of reading use case #2. Is this what you
meant?
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
