Hi Darren,
This looks really good. I do have some comments/questions though. I
tried not to repeat others comments but if I had something additional to
ask or say even if it is a repeat I included it here.
Page 11: XML import:
It isn't clear to me how a class knows whether it can handle the
translation of itself from xml? What would be the cases we could not
handle this? Wouldn't some class that is defined have to return true?
Note: whether from_xml() will also create and populate the child
objects that are required
to represent the given XML DOM is undecided at this point.
How else would we generate the child objects for the XML that is being
imported? It would seem that the XML would be representative, possibly,
of a parent and children. And, all in one chunk of xml, so I am not sure
how we would manage the creation or the child objects if the parent
didn't do this?
Section 3.4.2.1: Singleton DataObjectCache class.. I know that you have
discussed it with Dave, just another comment to add to why this is done
this way. When we defined the architecture it wasn't clear that the
Engine actually had to use the Data cache. The application created it
through the engine and other components were storing and retrieving data
from there. The thing that was missed was the engines need to store
things such as checkpoints. It seems though, just to play devils
advocate, that the application is registering the checkpoints and that
it could add this data to the DOC after the checkpoints are registered
as opposed to Engine using the DOC directly.
I see from your use cases that the engine utilizes the store checkpoint
data to know what to execute in what order. I think the initial
assumption in the architecture was that the checkpoint data would be
stored in the Engine itself, not in the Data cache.
For AI, dumping of the checkpoints isn't required. We don't expose those
directly to the user. For DC it is required, however, we are not
planning at this time to have the ability to dump DC manifests. If these
assumptions are correct, is there any reason the engine can't store the
checkpoints within its own structure and allow for updating and
inserting of these so the Engine doesn't have to interact with the DOC?
What are the benefits of having the checkpoint data in the DOC? It seems
as if we could have the Engine snapshot itself, if this is the concern,
and that data could be restored at application restart or resume.
Are there other use cases for the Engine->DOC interaction beyond
checkpoints that the Engine has with the DOC?
I am not saying what you are doing is wrong, but if we are following the
architecture it seems as if we can have the Engine manage more of this
data for us. I could be missing something though.
Section 4.2-Use case #1:
In the architecture it is defined that the application calls the engine
to set_data_collection, and that from this the Engine instantiates the
DOC instance. Is there a reason we have this initiating from the Engine
without application request?
thanks,
sarah
******
On 05/19/10 08: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
