[libvirt] [RFC] Comfortable lookup functions interface/block stats

Daniel P. Berrange berrange at redhat.com
Thu May 15 15:13:21 UTC 2008


On Thu, May 15, 2008 at 05:04:38PM +0200, Stefan de Konink wrote:
> On Thu, 15 May 2008, Daniel Veillard wrote:
> 
> > On Mon, May 12, 2008 at 01:35:33AM +0200, Stefan de Konink wrote:
> > > Hi,
> > >
> > > Wouldn't it be much nicer for Joe Programmer if the API facilitated the
> > > functions:
> > >
> > > char ** virDomainInterfacePaths(virDomainPtr dom);
> > > char ** virDomainBlockPaths(virDomainPtr dom);
> > >
> > > I really don't get why XML parsing should be done for something that is
> > > almost too trivial to export. Any reasons why not to do implement this?
> >
> >   Hum, how would you use the paths out of their context ? I doubt
> > Joe Programmer would have much use for a list of paths without knowing
> > what they are used for.
> >   But maybe I didn't understood your APIs suggestions...
> 
> If Joe Programmer needs to parse the XML file to fetch 'hda', 'hdb' why
> not get them directly from the api?

Because they might want more information than just 'hda', 'hdb' and we don't
want to expose an every increasing set of APIs to get each individual piece
of metadata associated with disks. As you can see from the XML there is
alot of metadata and we add more surprisingly often. This is why we use the
easily extendable XML format for providing all this metdata.

As for parsing the XML  - if you really only need that one attribute, then 
don't parse & iterate over the Dom. Use an XML lbirary suppporting XPath
with an expresion like "/domain/devices/disk/target/@dev" which will give
you all the disk device names in a single go.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list