Re: [PATCH] add xl ocaml bindings

[Vincent Hanquez <vincent.hanquez@eu.citrix.com>]

On 28/06/10 10:59, Ian Campbell wrote:
> Not really a comment on this patch as such but more a related thought...
> How many language bindings do we think there are going to be and how
> much effort do we expect it would be keeping them all (or even just the
> interesting subset) up to date?
>    
I'm not sure if you're asking generally in terms of languages or in 
terms of bindings. I think from the point of view of bindings, that was 
the only thing left that required a binding. in terms of language, I 
don't really know if anyone is going to add some python bindings or not. 
it depends if xend is going to die, or is going to be ported.

effort wise, it's hard to answer since it depends on lots of variables. 
for example, API stability of libxenlight.

> Is it worth investing the time up front to define a (simple) IDL and to
> generate the C header and language bindings from that?
>
> Are there any existing IDLs which would meet our needs?
>    
Theoretically, yes. pratically there's no IDL that i know of, that 
generate anything remotely close to be good or even useful. (it's maybe 
no surprise that all the python bindings are not autogenerated either)

swig seems to generate bindings really close to the C layer which make 
it quite annoying since the ml glue code become quick thick and quite 
annoying to write (converting back and forth types) and i've never 
actually tested the output of swig, and last time i tried camlIDL on a 
simple example, it generated a code that would segfault.

one more thing about generic bindings generator, is that it's hard to 
provide nice and clean interfaces. most of the time you stay really 
close to the C layer, which defeat the whole point of using a high level 
language for the user.

FYI, I've rewritten a little program to help me generate the bindings 
actually, but yet, it's quite painful to get right (and it's not in any 
Xen-friendly language either), and in the end i decided to take some of 
the output and fix it up by hand. in any case, it's really really far 
from having a automatic "./program idl > code" step in the code.

> the libxl interface from needing to know enough about each language to
> fixup the bindings (or else they may break the build). At least in the
> normal case where the change does not require a change to the IDL then a
> simple regeneration should be enough to update the bindings for the
> change.
>    
hopefully in most cases, as long as everything doesn't change too badly, 
adding fields is relatively easy even for someone that doesn't know ocaml.

-- 
Vincent