Hi Alok, Thanks for the feedback, comments/responses below...
On 05/22/10 12:22 AM, Alok Aggarwal wrote: > Hi Darren, > > On Fri, 21 May 2010, Darren Kenny wrote: > >> Hi, >> >> I would like to just remind people that we are seeing some feedback on this >> document (I'll repeat the URL for completion): >> >> http://hub.opensolaris.org/bin/download/Project+caiman/DataObjectCache/DataObjectCache%2DDesign%2D0.5.pdf >> >> We would really like to get as much feedback on this by next Tuesday (May >> 25) if >> possible to allow for "digestion" for the Install meetings on Thursday, so if >> you're looking for some light reading at the weekend... ;) > > Section 3.1 - third para. Could you please clarify what > this is saying? Hmm, does read a little weird ;) What I am trying to say here is that because the DOC is the center point for all data regarding an install, it is then possible to use this fact to generate an XML manifest - and then later, if using this manifest re-create the DOC from the manifest to re-perform an install. While the XML Manifest doesn't reflect ALL contents of the cache (only the snapshots will do that) - it should be sufficient to re-create an install. > > Section 3.2, bullet 3 - "Consumers of the API ..." Would > it still be okay for DC to have, say, references to the > Transfer data that it got from the DOC, which it in turn > Section 4.2 - last line on page 22 - In this case, is the > is used to instantiate the Transfer object(s) by DC? I'm not really sure what you mean here - seems like some cut/paste confusion ;) But here's how I'm interpreting it: Section 3.2, bullet 3 - "Consumers of the API ..." Would it still be okay for DC to have, say, references to the Transfer data that it got from the DOC, which it in turn is used to instantiate the Transfer object(s) by DC? Ideally no, since that 'Transfer data' is what's stored in the DOC - so could (in theory) be rolled-back, making it invalid, in that anyone taking it from the DOC will be getting a different object to the one you're referencing... Of course it's alright to hold on to it for the duration of a method, but I wouldn't think that it should be any longer than that. Section 4.2 - last line on page 22 - In this case, is the I'm not sure what you wanted to say here. > > Section 3.3 - Should there be an interface that allows > for marking specific child objects as having been instantiated? > I'm thinking specifically in terms of Target instantiation > and Transfer where there may be multiple children to > instantiate. I don't think that's part of the DataObject class itself since it's specific to the implementation area - in other words, not all objects need this. As such, this would probably be something that a Target base-class might have and allow for sharing among all Target classes. Maybe if you have more details about what you're thinking here I could be more specific. If it's something that would be more generic (and this is why you're asking) then the most likely solution would be to have another intermediate class something like "InstantiateableDataObject > > Section 3.4.2.2 - Will the application call the snapshot()/ > load_snapshot() interfaces at all? I actually think the Engine > will need to call these interfaces but I just want to be sure. As far as I'm aware the Engine is the most-likely to call snapshot() but the load_snapshot() would probably be more likely to be called by the Application as part of some "control" mechanism (e.g. the UI or restarting DC from a given point in time, etc). > > Section 3.4.2.3 - I'm assuming that the Manifest Parser > after validating the manifest will populate the DOC. What > is the use case for import_from_manifest_xml() then? While it's true that the ManifestParser is primarily responsible for populating the DOC, it is expected that most of this will be done by handing off the XML to DOC conversion to the DOC using this method. Dermot might be better able to confirm this since he's looking at the ManifestParser to DOC work... > > Section 4.5.1 - I'm assuming the Engine will be responsible > for bootstrapping the cache in this case as opposed to DC itself? No, I see it as being done by the Application, which is the one that controls which snapshot to load for resuming from. The engine will only take regular snapshots. So you would have the Application call DataObjectCache.load_snapshot() and then call Engine.execute() - the engine will then continue based on the state of the data in the cache. > > Section 4.6.1 - I don't believe the ManifestParser will be > responsible for locating and downloading the manifest. Instead > AI entities such as manifest-locator and service discovery > will be. ManifestServer will just get the manifest handed to > it. Hmm, you probably know better here - I've never seen these specifically called out anywhere and that ManifestParser was always the starting point in any of the other documents I've seen, as such I've always assumed it was the one to do the loading/sourcing of the manifest. If that's true then I would be expecting ManifestParser to be come much smaller than it is - if not totally removed - with much of it's knowledge about how to convert to/from XML being pushed into specific objects themselves. Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
