On Wed, Nov 23, 2016 at 08:48:43AM +0100, Michal Privoznik wrote:
I've came across this site [1] which refers to yet another Go
libvirt bindings. Add them to the list.
1:
https://www.digitalocean.com/company/blog/introducing-go-qemu-and-go-libv...
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/bindings.html.in | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/docs/bindings.html.in b/docs/bindings.html.in
index 7fe26df..6f18c07 100644
--- a/docs/bindings.html.in
+++ b/docs/bindings.html.in
@@ -15,8 +15,18 @@
<a href="csharp.html">C# bindings</a>.
</li>
<li>
- <strong>Go</strong>: Kyle Kelley et al. are developing
- <a
href="https://github.com/rgbkrk/libvirt-go">Go
bindings</a>.
+ <strong>Go</strong>: There are two bindings available:
+ <a
href="https://github.com/rgbkrk/libvirt-go">libvirt-go</a... and
+ <a
href="https://github.com/digitalocean/go-libvirt">go-libvirt...;.
+ <p>
+ The <tt>libvirt-go</tt> bindings are developed by Kyle Kelley et
+ al. and are built on the top of libvirt's client library.
+ </p>
+ <p>
+ The <tt>go-libvirt</tt> bindings are then developed by Ben
+ LeMasurier et al. and they hook straight into libvirt's RPC and thus do
+ not rely on <tt>cgo</tt>.
+ </p>
I really think we should *not* encourage use of this binding, on the basis
that we really don't want people hooking into the RPC system like this. It
makes them less future proof and locks them out of using any of the drivers
that are outside libvirtd, unless they want to tunnel access to them via
libvirtd which is just stupid.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://entangle-photo.org -o-
http://search.cpan.org/~danberr/ :|