[libvirt] [PATCH 2/2] docs: List go-libvirt in bindings

[Michal Privoznik]

On 23.11.2016 10:24, Daniel P. Berrange wrote:
> 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-libvirt/
>>
>> Signed-off-by: Michal Privoznik <mprivozn at 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</a>.
>> +        <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.

Fair enough. Frankly, I was surprised they do this and I am not in
favour of them doing so, but I thought that shouldn't stop me from
proposing this patch.
Another reason is that there's not strictly 1:1 relationship between a
libvirt API and RPC call. So after all I'm okay with dropping this patch.

Michal