Hi Darren.
Thanks for this thorough document. Here are my comments:
Bottom PP, page 4: Regarding snapshots, how come a second form of saving
the data is needed? I can see a slight performance advantage to saving
in raw form, but probably not noticable. Is there some other reason?
2.2: To me, the last PP of 2.2 seems to contradict itself. How can the
individual object stored in the DOC not be tightly coupled to the
structure of the data tree and yet the DOC keep track of how the pieces
fit together? Does "structure of the data tree" mean *how* the tree is
assembled vs the tree's contents?
2.3 Please explain the first 2 PPs a little more. The DOC
implementation should not be coupled in any way to the data it is
storing. To do so would limit the DOC's usefulness, flexibility,
adaptability, reusability, etc.
3.1, second PP: do you mean "...and to later restore a saved snapshot to
roll back to a point in time."
3.2: bullet 3: I think you mean local copies instead of local
references, correct? Referencing data in the cache from a means other
than the API should be not supported.
3.2 bullet 4: what is an example of a problem object created from
dynamically-executed code?
3.2 bullet 5:
- "Objects that are to be included..."
- by "generated" you mean a manifest created to save the data, right?
- sub-bullet 2: Here I assume the re-creation is when the saved XML file
is read back in again. What would be a case where data wouldn't be able
to re-create itself? Seems that if there is some nuance that couldn't
be re-created, there would be a field missing in the saved data.
3.3: Items mentioned elsewhere in the document that are missing from the
table:
- insert_child_before()
- insert_child_after()
- import_from_manifest_xml()
- NameValue class
- DataObjectDict class
- snapshot_to_path()
- load_snapshot_from_path()
3.4.1.1 "children" bullet: grammar nit: "An object may be a leaf-node in
the tree in that it has no children..."
3.4.1.2:
- insert_child_before() and insert_child_after are missing from table 3.3
- First sentence of copy() PP can be clarified. How about this:
"This method copies only the called object, not its children."
- Seems that the given methods require a node path to be
traversed one level at a time. Might it be helpful to have a
high-level method that does this? Further, the node path can
have names and types as part of it, to narrow the search by
values found along the way.
3.4.1.3:
- to_xml(), second bullet, second PP:
- Sentence needs some cleanup: Suggest: "The XML tree...
object itself. The children of the object will themselves
be asked for..."
- I believe that disallowing more than one node to be
generated from an object would help enforce better structure
and clearer code. Is there a use case for generating a
whole subtree from an object where generating a single node
would not work, or work as well?
- code snipet, from_xml():
- should the fourth line be:
new_obj = dataobject_type.from_xml(xml_node)
instead of to_xml?
- Should "current_root.append_child(new_obj) be part of the
"if" clause?
- Is there a use case where static registration be more useful
than dynamic registration? I'm wondering if dynamic
registration is all that is needed.
3.4.2: "The DataObjectCache class is the..."
3.4.2.2:
- third PP: "Pickle does this recursively..."
- Using Streams, second bullet:
- What does the integer read() argument represent?
- "Thus file can be a file object...": What is "file"? Is it
an arg to a method? Where is it defined in this document?
3.4.2.3: import_from_manifest_xml() is missing from table 3.3
3.4.3.1:
- NameValue and DataObjectDict classes are missing from table
3.3
- Not sure if having a NameValue class buys much when there is
already a DataObjectDict class. Unless there may be many
single name/value pairs (and the code would be muddied by
putting each in their own DataObjectDict), I suggest having
only DataObjectDict. Why complicate by introducing multiple
ways of doing the same thing?
3.4.3.2: Question: Could writing your own container class be good for
dynamically generating a value based on other values?
Diagram 1:
- DataObject: nit: deepcopy is missing ()
- DataObjectCache: the following are missing from table 3.3:
- import_from_manifest_xml()
- snapshot_to_path()
- load_snapshot_from_path()
Diagram 2:
- DataObject: the following are missing from table 3.3:
- get_children_by_type()
- add_child() - note: append_child() is in table 3.3
- get_children_by_name()
- note: get_children() is in table 3.3
- get_descendants_by_name()
- note: get_descendants() is in table 3.3
- I didn't check other objects in this diagram in this way...
Diagram 3:
- DataObject at the top has from_xml() correctly returning a
DataObject, but other objects have from_xml() returning a
boolean. Is this intentional?
Thanks,
Jack
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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
