6:35 p.m.
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?
Stefan
9:33 a.m.
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...
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
10:04 a.m.
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?
Stefan
10:13 a.m.
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 :|
6:48 a.m.
On Mon, May 12, 2008 at 01:35:33AM +0200, Stefan de Konink wrote:
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?
Yes, I tend to agree that parsing the XML is a pain. On the other
hand you can write the functions above pretty quickly using libxml2
and XPATH. Perhaps the easiest solution is some example code?
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
5 a.m.
On Mon, May 19, 2008 at 12:48:59PM +0100, Richard W.M. Jones wrote:
On Mon, May 12, 2008 at 01:35:33AM +0200, Stefan de Konink wrote:
> 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?
Yes, I tend to agree that parsing the XML is a pain. On the other
hand you can write the functions above pretty quickly using libxml2
and XPATH. Perhaps the easiest solution is some example code?
There are simple XPath wrappers for libxml2 in the src/xml.c module.
Things like virXPathString, virXPathNumber or virXPathNode.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6060
days inactive
6069
days old
5 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones -
Stefan de Konink