GSoC 18 Weekly Updates

This page details a summary of the activities undertaken for each week.

Added sanitytest.js to track implemented function count
We now generate all enums
Added support for vir.ListAll. functions
Whitelist all libvirt functions (failing functions are commented out with the error)

Major refactoring to allow:
- Adding file dependencies at runtime
- Adding ability to override default generators (and manual implementations)
- Adding support to generate library level functions (eg. libvirt.open, etc.)
- Adding support to generated enums at library level
Started Architecture documentation

This week brings an important milestone -- End to End generation (js + C header + C impl + napi export)
- Example highlighted using virDomainGetVcpusFlags
Adding e2e generation for primitive types adds support for generating wrappers and napi exports

Created Parser/Generator rough prototype
- We're able to generate virConnectOpen
  - pending one small (expected) issue: generalising checking for error returned from libvirt (be it null pointer or eg. -1)
Created partial virConnectRegisterCloseCallback implementation pending some clarification on usage.

Repository (branch) cleanup to move things along
- Merged PR1 Initial_code into master
- Merged PR5 generator into master after resolving conflicts
- Closed PR2 and PR6 proof of concepts
Created travis CI to run on PRs
Opened PR for initial Override and manual infrastructure to enable overridding generated functions (although we don't have the generated stubs yet)
Committed manual implementation of virConnectClose and partial virConnectRegisterCloseCallback (but still requires some work before PR)..
(Started work on API parser, but nothing useful yet)

Created a PR to create generation infrastructure, this includes
- A generator script that (for now) just outputs the previous manual code to files
- A bunch of npm scripts to:
  - check libvirt version / api xmls / etc.
  - run the generate script
  - install and test
- a makefile to wrap the npm scripts
Created proof of concept for defining js interface using node-addon-api (wrapping c++ objects).
- My main aim was to highlight that we can arrive to something like this where with a bit of framework forwarding calls is a(n easily generatable) one liner
- However I still stand by our decision to expose the API as a JS API. I think we're now in a good position to fill out the JS vs. C(++) API design decision
I tried to get in touch with the node-libvirt contributors in hope to schedule a few minutes to discuss any difficulties/hacks they had etc. however no response just yet.

Defined an initial list proposal of the minimal manual bindings needed before starting with the generator.
- Covers the creation of each libvirt "class" (apart from secret, stream, and event)
- Attempts to cover some non uniform cases
Updated pull request for our initial manual bindings, getting us slightly closer to the target template.
Created proof of concept for defining the js interface using the napi API
Design Decisions: NodeJS Binding API writeup

Deeper look into:
- node_api (C lib) vs node-addon-api (C++ lib)
- libvirt-python's client API
- node-libvirt's client API
94e6131: Added manual bindings for virConnect, virDomainLookupByName, virDomainGetID following libvirt-python's API style

Provide feedback