Dave,
Thanks for the thorough review. I'm just responding to a few selected
items for now:
On 05/21/10 19:54, Dave Miner wrote:
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?
I'll try to provide a more complete description for this.
(It was a relatively obscure problem that arose during prototyping
where pickle got confused about the path to objects that were
created from dynamically loaded code, so it gave an error like:
Can't pickle <class 'cache/pick2.MyClass3'>: it's not found as
cache/pick2.MyClass3)
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
These interfaces are only intended for other Install apps to use, so
Consolidation Private seemed like the most appropriate value. I'm happy
to take guidance on what the correct classification should be if you
think another value is more appropriate?
levels). Are you intending a later update (once you've gone further
into implementation) with an imported interface table?
Someone mentioned (when I was reviewing a different design doc) that
Imported Interfaces were beyond the scope of these designs, so I
removed it. Should I put it back in?
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
I think a given class would either always or never return XML.
It wouldn't be expected to deduce from the context whether it
needs to - that would just make the code too difficult to follow.
At this stage we're still not certain whether it's more convenient
for users to have the top-level object return all the XML for
itself and all of its descendants, or if it's better for each
class to just return the XML that represents itself and leave
the Data Object Cache to put it all together. So, we allow either
method.
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.
Dynamic registration would probably need to depend on all the relevant
modules being loaded in Python before you need to import an XML manifest.
eg the mechanism might be that the module's (or packages's) __init__.py
file contains some code to register the classes. If, for some reason,
the relevant "import X" or "from Y import Z" commands have been been
executed before the manifest is processed, then the DOC will not know
about those classes and cannot call their can_handle() or from_xml()
methods.
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).
I think a singleton is the obvious design choice here, as you will never
need a 2nd data cache (indeed, it might only cause confusion) and having
a singleton gives you the advantage of being able to access the DOC from
any component, without a middle man, via a get_instance() class method.
It seems awkward to have to go through the Engine to get a reference
to the DOC.
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.
This depends partially on how the final Manifest Schema looks, but it might
be that only targets that have an "action" associated with them, get
written to the manifest?
- Dermot
Dave
_______________________________________________
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
