On Fri, Sep 28, 2007 at 03:45:31PM +0100, Daniel P. Berrange wrote: > On Fri, Sep 28, 2007 at 02:52:51PM +0100, Richard W.M. Jones wrote: > > # src/virsh capabilities > > [...] > > <topology> > > <cells num='1'> > > <cell id='0'> > > <cpus num='4'> > > <cpu id='0'/> > > <cpu id='1'/> > > <cpu id='2'/> > > <cpu id='3'/> > > </cpus> > > </cell> > > </cells> > > </topology> > > Do we really need such verbose XML. At the very least the 'num' attribute > is redundant, since you can trivially do count(/topology/cells/cell) or > count(/topology/cells/cell[@id=0]/cpus/cpu) XPath exprs in both cases. > > The addition of extra tags every time we have a list is not the style we > have normally used in libvirt. eg, we don't use > > <disks> > <disk> > .. > </disk> > <disk> > .. > </disk> > </disk> > > to surround the list of disks in a domain. > > I'd prefer to see it looking more like this: > > <topology> > <cell id='0'> > <cpu id='0'/> > <cpu id='1'/> > <cpu id='2'/> > <cpu id='3'/> > </cell> > </topology> I explained why I preferred a more structured approach and the <cells> construction when I made the proposal https://www.redhat.com/archives/libvir-list/2007-September/msg00015.html basically you may hit hierachical topologies which are not flat. If you want to remove the nums= that mean that from an user perspective if you use a streaming interface (like SAX) you can't know a priori the size of the arrays you need to allocate to fill the information. I prefer something a bit more verbose and a bit more complex to generate but more flexible in its use. For me <cells> can't go away for structural needs and the count is for the number of children at that level not at all levels. We could get rid of <cpus> but <cpus num='4'> <cpu id='0'/> <cpu id='1'/> <cpu id='3'/> </cpus> could allow things like description in hotplug CPUs situations where the structure/topology does not change but the content does. Since that part is rather experimental, I prefer to have more structure than what may looks like sticly necessary right now but have provisions for the future. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list