On 05/25/10 06:34 PM, Sue Sohn wrote:
On 05/21/10 01:45, 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... ;)
>
> Thanks,
>
> Darren.
Hi Darren,
1.1 Might be worth also mentioning the Text Installer in the second paragraph.
Will add it ;)
3.3 Should the exported interface table have all of the methods in the doc? Some
are missing, such as the insert_child methods.
Hmm, yes it should, must have missed that... Thanks.
3.4.1.2 - Seems like these insert and append operations might also be useful for
multiple children. Maybe delete too.
Yes, Keith mentioned this too w.r.t. delete, will make it possible to take a
tuple/list as an argument, and adjust execution accordingly.
3.4.1.3 example code in box:
Should the the append_child line be above the break and should the break be
indented another level? Also, don't you want the new_obj line to be using
from_xml rather than to_xml?
Yes, the break should be indented, and it should be from_xml, yes.
3.4.2 Reading "Another requirement of the Data Object Cache" made me wonder what
the other requirements are. Perhaps a section in the front of the document
listing requirements might be worthwhile.
The requirements are listed in section 1.1, but probably should be a heading of
it's own to allow easier location...
3.4.2.4 The description of dump should describe what indented means in
dump(indented)? Is it simply a boolean of whether to indent?
True, but likely we will remove this in favour of just having a str()
implementation that performs the same function.
4.1 last paragraph on p17
mentions get_parent() method, but don't see this method mentioned earlier.
Should this be added to section 3.4.1.1 under parent? Similarly, Diagram 1 shows
a get_name() - maybe this should be referenced in 3.4.1.1 also?
My mistake, at one point they were called get_name/parent - but now it's simply
a read-only property that you reference as obj.parent or obj.name.
Diagram 1 on p19:
DataObject:
o Remove delete_all_children() method since 3.4.1.2 says delete_children() with
no params deletes all children.
Yep, a last minute change...
o And while you're in there deepcopy needs "()".
Yep.
o Is get_all_children() still valid? It wasn't mentioned in 3.4.1.2.
No it's not, again last minute change - get_children() with no params will
default to all children (as will read-only .children property).
DataObjectCache:
o should snapshot_to_path and load_snapshot_from_path be removed from the list
since the snapshot() and load_snapshot() methods can accept either file object
or path?
Yes.
4.4.1 Is there a get_child_by_name method? This example in the box is the first
reference to it in this document. Or does one call get_children with the name as
a passed parameter? If so, this section as well as 4.8 should be updated.
Yep, another one...
4.7 if a particular object needs to be stored in the cache, but is not intended
to be listed in the manifest, should to_xml() return None per 3.4.1.3 rather
than a NULL XML element?
Yes, None is correct...
And finally, a few typos/nits:
3.1 second paragraph:
and to be then later restore -> and to then later restore
yep
3.4.1.1 under children:
that it has not children -> that it has no children
yep
3.4.1.2 under copy() (and several other places in document)
It's -> Its
Dermot, you missed these - normally you're always noticing these ones! ;)
