7:16 p.m.
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
9 p.m.
On 03/11/2010, at 11:22 AM, Arnar Mar Sig <antab(a)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
9:55 p.m.
On Nov 3, 2010, at 2:00 AM, jclift(a)redhat.com wrote:
On 03/11/2010, at 11:22 AM, Arnar Mar Sig <antab(a)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
9:40 p.m.
On 03/11/2010, at 11:22 AM, Arnar Mar Sig <antab(a)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?
9:51 p.m.
On Nov 3, 2010, at 2:40 AM, jclift(a)redhat.com wrote:
On 03/11/2010, at 11:22 AM, Arnar Mar Sig <antab(a)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
10:57 p.m.
On 03/11/2010, at 1:53 PM, Arnar Mar Sig <antab(a)antab.is> wrote:
On Nov 3, 2010, at 2:40 AM, jclift(a)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. :)
12:03 a.m.
On Nov 3, 2010, at 3:57 AM, jclift(a)redhat.com wrote:
On 03/11/2010, at 1:53 PM, Arnar Mar Sig <antab(a)antab.is>
wrote:
> On Nov 3, 2010, at 2:40 AM, jclift(a)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
12:35 a.m.
antab(a)antab.is :
> 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.
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
5133
days inactive
5133
days old
7 comments
3 participants
participants (3)
-
Arnar Mar Sig -
jclift＠redhat.com -
Mihamina Rakotomandimby