Autogenerate go-client from XenAPI IDL

[robhoes]

Rather than adding each API call by hand, it may be easier to automatically generate the bindings from the IDL? This is how all the other bindings are done.

There are (at least) two ways of doing this:

1. Integrate directly with the OCaml-based API definitions, as done for the existing bindings in https://github.com/xapi-project/xen-api-sdk.
2. Write a generator that reads in the API definitions from a JSON file that is exported from the OCaml-based IDL. This is what the new XenAPI docs on http://xapi-project.github.io/xen-api use (see https://raw.githubusercontent.com/xapi-project/xapi-project.github.io/master/_data/xenapi.json for the JSON file). This way, you can write the generator in any language you like, including golang :)

[rdobson]

Yep, completely agree. I've spoken with Dave about this and it would be good to do when someone has time. The second option looked to be the simplest :)

[djs55]

I think it's valuable to get a bit of real world experience first, to find
out how the bindings should look. It's good to have answers to questions
like:

• do server "objects" map to objects on the client
• do transient errors like session expired get exposed to users, or do the
  bindings re-login for you
• do the clients get to manage the HTTP connections themselves or are they
  transparent

Actually thinking of connections, I recommend always opening 2 connections:
one for async commands and the other for task events. I'd like to change
the OCaml bindings so that even a sync call like vm.start gets converted
into an async one. This avoids opening too many connections when under
load. In the ocaml case I'm hoping to hide the expired sessions errors too.

Cheers,
Dave

On Monday, April 13, 2015, Rob Dobson [email protected] wrote:

Yep, completely agree. I've spoken with Dave about this and it would be
good to do when someone has time. The second option looked to be the
simplest :)

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

Dave Scott