On 05/19/10 10: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
Overall, a very well-written document. But, of course, I have comments :-)
2.1, third bullet: s/system/application/
2.2, last bullet: Would it more correct to say that it's the job of the
application to define the object hierarchy, and hence the data tree, and
that DOC is really just providing the infrastructure for the application
to do that? As written the DOC seems to be perhaps more omniscient than
you mean for it.
3.2 (sub-bullet of bullet 4) regarding the pickling requirements, is
there a specific reference or more concrete example that you could
provide to help ensure our object implementors get this right?
3.2 bullet 5: Are there things we can do to help object implementors
meet the schema consistency and re-creation constraints?
3.3 Is there a particular reason we need to constrain these to
Consolidation Private? (In reality, since install is not really
intended to be a separate consolidation, I'd prefer we avoided
consolidation and went with either Project Private or one of the public
levels). Are you intending a later update (once you've gone further
into implementation) with an imported interface table?
3.4.1.1 Is there a reason not to require that names within a class be
unique? Not being able to depend on this seems to make some of the
other interfaces where retrieval/deletion can use names less useful.
3.4.1.2 Seems like it would be convenient to have a variant of
delete_children that can take a list (such as a list returned from
get_children).
3.4.1.3 to_xml(). I like the potential choice to have a parent generate
a tree for its children, but I'm not sure how a general child class
would know to return None if it were implemented to normally provide its
own representation; especially if the parent would like to use the
child's to_xml() to assist in its aggregation. Should it perhaps be the
case that to_xml() also returns a boolean that indicates whether descent
within this object's subtree should continue? Should this also apply to
can_handle()/from_xml() so that the behavior can be fully symmetric?
Finally, can you expand on the factors that are important to consider in
the decision between static and dynamic registration? My assumption
would be to lean strongly towards dynamic for flexibility of this
infrastructure, but I'm guessing there are factors that I'm not considering.
3.4.2.1 A singleton here seems somewhat controversial to me. Why isn't
it the application's responsibility to control this? An alternate
formulation that I think accomplishes the goals here is to have the
application provide the Engine with an instance, and the Checkpoint
objects can always get it from their associated Engine. Are there cases
that this doesn't work for? (I didn't attempt to map this to all the
use cases so I'm not necessarily asserting it will, but it seems the
more natural solution to me so I'm wondering if you considered it).
3.4.2.4 Wouldn't clear() be useful in applications like the interactive
installers where the user might go back to the first step in the parade
of screens (might be useful as a variant of Use Case 1)? Also, I didn't
grok what "dump( indented )" is supposed to mean?
Diagram 2, page 20 I don't think it really matters from your design
point of view (probably helps the diagram to consider it this way :-),
but I expect that the current ICT glob will be re-implemented as
individual checkpoints.
Diagram 3, page 21: s/Parition/Partition/
page 25, first paragraph regarding writing out checkpoints to the
manifest: Seems like we need a mechanism for the application to inform
each checkpoint of whether it's to be written out or not. Not sure
where that falls architecture-wise.
4.4.1 NOTE: Does this also imply that checkpoints should be more or
less stateless?
4.5.1 Should you clarify that controlling the writing of execution
status to a persistent store is a function of the application and/or
engine, not the DOC?
4.8 One thing that seems missing to me is how the application can prune
the targets that will be dumped into a manifest to just the ones that
were selected? All the other discovered target data seems to be noise
in terms of using the manifest in the future.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
