Hi Sarah,
On 05/25/10 05:14 PM, Sarah Jelinek wrote:
> 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?
I think that Dermot explained this part, but if you need more let us know.
>
>> 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?
When looking at a piece of XML, the default behaviour is that the parent
object would only handle it's own tag, and create the object to represent it,
and the creation of the children would be done by an object that correctly
represents it.
But, it is always possible that an object could also handle the child nodes - I
think it would all depend on how complex the situation is, this is a decision
that needs to be made at implementation time.
An example that I'm thinking of is in the case of the Transfer IPS case, where
there are a list of packages - you may not want to have an DataObject
representation of each package, but instead just store them as a list of
strings in the TransferIPS class, e.g.
<transfer name="IPS1" type="IPS" repo="...">
<package fmri="...."/>
<package fmri="...."/>
<package fmri="...."/>
</transfer>
>
> 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.
The assumption is that anything that is to be output in the manifest would be
stored in the DOC - this would imply that the checkpoints would then also need
to be stored in the DOC, and I thought that was what we agreed on recently
when we spoke, did I get that wrong?
>
> 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?
If there is not a requirement that checkpoints would ever be stored in the
manifest, then there is no requirement to have then in the DOC at all.
I admit that I'm getting confused as to whether they should be in the DOC or
not, almost every time we broach the subject it seems to change.
> 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.
The main reason for having the checkpoints in the DOC was to allow for writing
to the manifest - and also reading from the manifest using Manifest Parser,
which was indenting on doing the parsing by putting things into the DOC...
>
> Are there other use cases for the Engine->DOC interaction beyond
> checkpoints that the Engine has with the DOC?
I don't believe that the Engine itself would have any other dependency on the
DOC - it's the Application, ManifestParser and Checkpoints that are the main
consumers of 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.
I believe that whether the Engine uses the DOC or not, is really a matter for
the Engine Design which I think needs to do what works best for it. As for the
design of the DOC itself I don't think it's too important since it's just data
as far as it's concerned.
>
> 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?
Actually, it makes more sense for the Application to do the initial creation
of the DataObjectCache class, along with the Logger - especially if the Engine
has no requirement of the DOC.
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
