3.4.1.1 Is there a reason not to require that names within a class be
unique? Not being able to depend on this seems to make some of the
other interfaces where retrieval/deletion can use names less useful.
One reason that we didn't restrict this is in the case of Targets, where you
may have something like:
Targets
TargetDisk [c0d0]
Partition [p0]
Partition [p1]
Slice [s0]
Slice [s1]
...
Slice [s7]
TargetDisk [c2d0]
Partition [p0]
Slice [s0]
Slice [s1]
...
Slice [s7]
As you can see the names in this case (partitions/slices) wouldn't be unique
in themselves, but would only be considered unique if you include the context
of the parents, i.e. c2d0/p0/s1.
I'm somewhat doubtful of that suggested taxonomy. A slice (or
partition) seems dependent on its parent device/partition, so I would
expect the names to be fully-qualified.
I don't believe that would be the case at the moment in the schema design:
...
<target_device>
<type>
<ctd>
<name>c1t0d0</name>
<slice>
<name>0</name>
<action>
<create>
<size>1000</size>
</create>
</action>
</slice>
</ctd>
</type>
</target_device>
...
I think that the fully qualified name is certainly fetch-able (e.g. calling
slice.get_device_name() ) but I don't think it should be necessary for a child
node to qualify it's name in itself, as in:
Targets
TargetDisk [c0d0]
Partition [c0d0p0]
Partition [c0d0p1]
Slice [c0d0s0]
Slice [c0d0s1]
...
Slice [c0d0s7]
TargetDisk [c2d0]
Partition [c2d0p0]
Slice [c2d0s0]
Slice [c2d0s1]
...
Slice [c2d0s7]
this seems like redundant information being repeated unnecessarily, when it's
possible to get it using full_name = name + parent.name ...
The current schemas do not not have children that have fully qualified
names. The plan moving forward was to keep this the same, and associate
a child with the parent, and get the full name that way. I agree with
Darren that storing the info in the child seems redundant.
As I said in my response to Darren that crossed with yours, one
significant, and somewhat valid, criticism of many XML schema is
perceived excessive verbosity. I would like to explore limiting that
where possible, and using direct, fully-qualified slice references seems
a particular point where that might be possible. It's also demonstrably
easier for sys admins to read, cut & paste, in that you don't have to
construct the device name (which is what you'd be using anywhere else)
from fragments in the schema. I feel like we need to be more human
here, and less engineers :-)
I do have a question though.. the delete_child() method indicates that
this will remove a specific parent class. Is this method on the parent
class so that you know which parent to use?
I suppose we could ask that the name would be unique in the any given child
list - but I don't think we could ask for it to be the case in the complete
tree of objects. This could also open up the ability to refer to children
using a dictionary, which might be useful...
That seems like a theoretical use, but it seems to compromise an
immediate, practical use of the Name to allow it, soI guess I'm
skeptical still.
And entitled to be ;)
3.4.1.3 to_xml(). I like the potential choice to have a parent generate
a tree for its children, but I'm not sure how a general child class
would know to return None if it were implemented to normally provide its
own representation; especially if the parent would like to use the
child's to_xml() to assist in its aggregation. Should it perhaps be the
case that to_xml() also returns a boolean that indicates whether descent
within this object's subtree should continue? Should this also apply to
can_handle()/from_xml() so that the behavior can be fully symmetric?
This is certainly possible to do. I'm honestly still delving into this area in
more depth to see what the best solution would be.
But my thinking on it is that if it's likely that the parent object would do
the XML generation to include it's children, then most probably the case that
the child wouldn't ever generate XML in itself.
I would think that if a parent is generating the xml for itself and its
children it would still rely on the child to provide its xml
representation. To aggregate the data into a tree. Is this not possible
or desirable for some reason? Why would we want the parent to generate
the xml for itself and its children without traversing the children?
I'm trying to explore here whether it's possible for an object to
aggregate other objects in such a way that it we can potentially provide
a flatter, more "usable" notation in the manifest(s), even though the
object implementation in the code might be deeper, thus making the
implementation somewhat less visible. So it's closely related, at least
right now, to the point above about device specification in the schema,
but might also translate to other things we'd like to encapsulate.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
