[libvirt] New PHP bindings
Hi There are few PHP libvirt bindings out there, but all I found are procedural based and incomplete. To address this I created another binding that is OO based and in large part generated from libvirt-api.xml. The extension already supports most of the API, split into 6 classes: virConnect, virDomain, virInterface, virNetwork, virStoragePool, and virStorageVol. Snapshot of the current code can be found at: http://libvirt-debian.vm.antab.is/files/php-libvirt.tar.bz2 Or using svn from: http://svn.antab.is/php-libvirt/trunk Build instructions are in the README file. Documents can be found at http://libvirt-debian.vm.antab.is/ NOTE: Most of the docs are copied from libvirt. It has mostly been tested with libvirt test backend and PHP unit tests (phpt) are used to test, covering about 40% of basic usage. It is by no means complete and missing some functionality like classmaps (So virConnect::domainLookupBy* can return user defined class extended from virDomain) and probably leaks memory. I would appreciate any input and comments. Thanks Arnar Mar Sig
On 03/11/2010, at 11:22 AM, Arnar Mar Sig <antab@antab.is> wrote:
There are few PHP libvirt bindings out there, but all I found are procedural based and incomplete.
To address this I created another binding that is OO based and in large part generated from libvirt-api.xml.
The initial though that popped into my head is "can these be merged with the php-libvirt bindings we're already advertising on the libvirt site?" Just from the point of view of an end user. It seems like it would be nicer to have one set of bindings available that does both, rather than a procedural one, and a separate OO one. (would both extensions even play well together if both loaded on the same server?) Regards and best wishes, Justin Clift
On Nov 3, 2010, at 2:00 AM, jclift@redhat.com wrote:
On 03/11/2010, at 11:22 AM, Arnar Mar Sig <antab@antab.is> wrote:
There are few PHP libvirt bindings out there, but all I found are procedural based and incomplete.
To address this I created another binding that is OO based and in large part generated from libvirt-api.xml.
The initial though that popped into my head is "can these be merged with the php-libvirt bindings we're already advertising on the libvirt site?"
Just from the point of view of an end user. It seems like it would be nicer to have one set of bindings available that does both, rather than a procedural one, and a separate OO one. As most of the code is generate, its not that hard to add a procedural interface too.
(would both extensions even play well together if both loaded on the same server?)
It will not work at the moment because of my bad naming choice:(
Regards and best wishes,
Justin Clift
Arnar Mar Sig
On 03/11/2010, at 11:22 AM, Arnar Mar Sig <antab@antab.is> wrote:
Snapshot of the current code can be found at: http://libvirt-debian.vm.antab.is/files/php-libvirt.tar.bz2 Or using svn from: http://svn.antab.is/php-libvirt/trunk
Ouch, also noticed yours are named "php-libvirt" too, same as the one's we're already linking to. :( That's going to be a real pain for people using a search engine. It's probably also going to make things uncomfortable for packagers (ie for Fedora and similar). They'll need to rename one of the packages to not have the same name as the other. Looking at the site, seems like you've put a fair amount of time into this. :) In the "Installation" section, one thing I'm wondering about is where it says: "There is no installation needed to use these functions; they are part of the PHP core." That doesn't seem right does it?
On Nov 3, 2010, at 2:40 AM, jclift@redhat.com wrote:
On 03/11/2010, at 11:22 AM, Arnar Mar Sig <antab@antab.is> wrote:
Snapshot of the current code can be found at: http://libvirt-debian.vm.antab.is/files/php-libvirt.tar.bz2 Or using svn from: http://svn.antab.is/php-libvirt/trunk
Ouch, also noticed yours are named "php-libvirt" too, same as the one's we're already linking to.
:(
That's going to be a real pain for people using a search engine. It's probably also going to make things uncomfortable for packagers (ie for Fedora and similar). They'll need to rename one of the packages to not have the same name as the other. Yeah, on second though it might not have been the best thing, but it started out as a little test and never though much about the name.
Looking at the site, seems like you've put a fair amount of time into this. :)
Took some time, but most of the text is copied from libvirt api docs, I will go over it soon, finialize it and add more examples.
In the "Installation" section, one thing I'm wondering about is where it says:
"There is no installation needed to use these functions; they are part of the PHP core."
That doesn't seem right does it?
Its the default from php docgen script, haven't done the install/configure part yet, just the methods to get something to help people get started. The build insturctions are in the README file at the moment. Arnar Mar Sig
On 03/11/2010, at 1:53 PM, Arnar Mar Sig <antab@antab.is> wrote:
On Nov 3, 2010, at 2:40 AM, jclift@redhat.com wrote: <snip>
It's probably also going to make things uncomfortable for packagers (ie for Fedora and similar). They'll need to rename one of the packages to not have the same name as the other. Yeah, on second though it might not have been the best thing, but it started out as a little test and never though much about the name.
Heh, I completely understand trying things out and seeing how they go. :) Don't get me wrong, I think this is good effort, and worth taking forwards. But, (and it's a big one) I *really* *really* want us to have just one _very good_ PHP library for libvirt if at all possible, rather than a number of competing ones that each do their piece ok. It can make it a bit harder up front, after you've got the general experimentation bit done to see if the idea is sound (which you're doing :>). But it's _generally_ the right approach if people can work together well. Radek, who is working on the PHP libvirt bindings we already link to, has a good attitude, is responsive, and is also putting a good amount of time into PHP bindings. Other people are submitting patches and testing things out too. It would be great if you guys could work together on getting your OO approach added in (please!) OO is so much nicer than procedural when a person gets the hang of it. :)
Its the default from php docgen script, haven't done the install/configure part yet, just the methods to get something to help people get started. The build insturctions are in the README file at the moment.
Cool. I won't try them out personally (other priorities atm), but others probably will. :)
On Nov 3, 2010, at 3:57 AM, jclift@redhat.com wrote:
On 03/11/2010, at 1:53 PM, Arnar Mar Sig <antab@antab.is> wrote:
On Nov 3, 2010, at 2:40 AM, jclift@redhat.com wrote: <snip>
It's probably also going to make things uncomfortable for packagers (ie for Fedora and similar). They'll need to rename one of the packages to not have the same name as the other. Yeah, on second though it might not have been the best thing, but it started out as a little test and never though much about the name.
Heh, I completely understand trying things out and seeing how they go. :)
Don't get me wrong, I think this is good effort, and worth taking forwards. But, (and it's a big one) I *really* *really* want us to have just one _very good_ PHP library for libvirt if at all possible, rather than a number of competing ones that each do their piece ok. It was not my intention to compete with Redek's work, but more to provide an alternative OO based extension.
It can make it a bit harder up front, after you've got the general experimentation bit done to see if the idea is sound (which you're doing :>). But it's _generally_ the right approach if people can work together well.
Radek, who is working on the PHP libvirt bindings we already link to, has a good attitude, is responsive, and is also putting a good amount of time into PHP bindings. Other people are submitting patches and testing things out too.
It would be great if you guys could work together on getting your OO approach added in (please!) OO is so much nicer than procedural when a person gets the hang of it. :)
I first looked at Redek's extension and its not bad, but i thought it would be too much work to extend it to support OO and instead opted to write one from scratch and generate most of the code. The codegen part saved me alot of time and as a proof of concept I changed it to generate procedural style interface also, so: $vir = new virConnect('test:///' . $test_def); $dom = virConnectDomainLookupByName($vir, 'fv0'); var_dump(virDomainGetName($dom)); is the same as: $vir = new virConnect('test:///' . $test_def); $dom = $vir->domainLookupByName('fv0'); var_dump($dom->getName()); This applies to all functions and the code for this is now in the svn repo (but not the tarball) Will take a little more work to add virConnectOpen(..) and fix virConnectDomainLookupBy* => virDomainLookupBy*, as i renamed them to go under virConnect.
Its the default from php docgen script, haven't done the install/configure part yet, just the methods to get something to help people get started. The build insturctions are in the README file at the moment.
Cool. I won't try them out personally (other priorities atm), but others probably will. :)
Arnar Mar Sig
Don't get me wrong, I think this is good effort, and worth taking forwards. But, (and it's a big one) I *really* *really* want us to have just one _very good_ PHP library for libvirt if at all possible, rather than a number of competing ones that each do their piece ok. It was not my intention to compete with Redek's work, but more to
antab@antab.is : provide an alternative OO based extension.
For the small experience I have in FOSS, joining (and improving) a project is better than starting from scratch. Let me give you the example of one LDAP Ocaml library http://ocamldap.sourceforge.net/ocamldoc/index.html and the famous PHP PDO :-) This has one functional/imperative oriented "side" and one object oriented one. If you want to provide a strong object orientation, I would suggest (dont get me wrong, it's just suggestion) you to join Redek and "plug" your OO pieace of code. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 34 56 000 19
participants (3)
-
Arnar Mar Sig -
jclift＠redhat.com -
Mihamina Rakotomandimby