Hi Darren,
Sorry for being a little late on these questions/comments. If I've got
dups, just say so and I'll go looking at past threads.
thanks,
-ethan
page 5 - 2.2 - Are there any assumptions on applications' reliance on the
order of interleaved elements as they appear in their xml instance files?
Or, to the point, it seems that order isn't tracked once imported into
the DataObjectCache. I think this is actually the correct thing to do and
keeps the design much simpler, but I think it should be noted here.
Reason is that currently, AI does take order of appearance to have
semantic meaning to it, but that just needs to be fixed in AI.
page 5 2.2 - Should high-level -> hierarchical ?
page 7 - 3.2 - Can you expound on what this statement is saying:
"For example, difficulties can arise when cache data contains
objects
created from dynamically executed code."
page 9 - 3.4.1.1 - "name". Does the statement "... used to identify a
specific object" mean a specific instance of an object, or specific class
of an object? In otherwords, will "name" be the same for all objects
of the same type, or are they unique for each instance of the object?
If the latter, then could you rephrase to say "... a specific instance of an
object."
page 9 - 3.4.1.1 - "children". I assume here that the children property
represents only direct children, and not all hierarchical descendants?
page 9 - 3.4.1.2 - I guess this goes back to my first comment. Is the
capability offered by this method here an attempt to allow applications
to dictate order?
page 10 - 3.4.1.2 - delete_children() - Just a clarification, but deleting
a child would in turn delete all of its children as well correct? If not,
what happens to its children?
page 10 - 3.4.1.2 - copy() - Perhaps its just my apprehensions from living
a non-garbage collected pointerful world the past few years, but the
behavior of this method seems like it could get hairy for both the consumer
and maintainer of this code. If its main use is for deepcopy(), have you
considered not exposing it? Or perhaps change the public exposure of it
to just copying the object at hand and explicitly not carry over children
references?
page 10 - 3.4.1.2 - get_first_child() - Why is this method needed? Couldn't
one just do get_children()[0] or some such to achieve this?
page 11 - 3.4.1.3 - to_xml() - What is the purpose or envisioned use case
for an object's to_xml() method to do the full true underneath it?
I'm assuming here that the recursion method to write out the cache
to an xml instance isn't the to_xml() method itself. If it is, then there
shouldn't be an option for to_xml() not to traverse its children.
Also, upon transforming to XML, is there any validation done on the
resultant instance document, if so when or where does that happen.
page 11 - 3.4.1.3 - can_handle() - "If a class doesn't generate XML, it
should simply return False from this method." Do we not expect that
we'd ever import Data from XML that doesn't ever go to_xml()? I'm just
curious as to whether this decision is made simply by choice or because
of some technical limitation.
"... the class implementation should look at Element passed, and by
looking at the tag, attributes, adn possibly child nodes, it should decide
whether it is able to handle the given element." I suspect that this check
could possibly give false positives in certain scenarios if a view of the
parent of the given Element isn't made available as part of the check.
If you disagree I can try to cons up an example to demonstrate.
page 12 - So what's blocking the choice of going 'Dynamically' here?
I don't see any disadvantages listed, and I can only think that it would
be advantageous to do it dynamically.
General comment: It would seem that an application is free to create a
tree of DataObjects that may not conform to what their elemental
representations are in xml form, and if so, are there any preventative
measures? Are applications just suppose to manage their own view of
what the DataObjectCache tree currently looks like? I sense that this
might be difficult to code toward. Also, the statement on page 5 - 2.2
says "It is the job of the DOC to keep track of the high-level XML
structure,
so that a properly structured XML manifest can be produced from the
installation data." But how is the DOC tracking this?
page 14 - 3.4.2.2 - load_snapshot() - Just for my clarification, this method
throws away any current tree data in the DataObjectCache being loaded
to, correct? Or perhaps, are there limitations as to when this method
can be called?
page 14 - 3.4.2.3 - import_from_manifest_xml() - Same question.
page 15 - 3.4.2.4 - Did you mean DataObjectCache here?
page 15 - 3.4.3.1 - DataObjectDict Class - how does the schema definition
for this look?? I would think the 'keynameX' shouldn't be element names
here, but instead something like:
<ddata name="DICTIONARY NAME">
<data key="keyname1">value1</data>
<data key="keyname2">value2</data>
....
thanks,
-ethan
On 05/19/10 07:34, 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
