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?
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?
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.
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.
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?
Section 4.5.1 - I'm assuming the Engine will be responsible
for bootstrapping the cache in this case as opposed to DC itself?
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.
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
