On 05/25/10 04:05 PM, Dave Miner wrote: > >>>>>> 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 think that the version I had is more cut-n-paste-able (is that a word?) if repeating the same thing in the manifest for another disk - so I think it all depends on what you're doing with it ;) > >> 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. I don't see why this shouldn't be possible if desired - I guess it'll finally depend here on the schema used - but if nothing else, to allow for it, would allow the schema to change in this way in the future with less impact on code. Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
