Re: [PATCH] add xl ocaml bindings

[Zhigang Wang <zhigang.x.wang@oracle.com>]

I did some investigation on python bindings. It seems the best way today is
using ctypes.

There are a few tools to autogenerate the bindings, but in my mind, the best way
is: generate at first time and then make some changes and maintain it manually.
I think user readability is most important.

And I was thinking xl should written in python.

Thanks,

Zhigang

On 06/28/2010 07:30 PM, Vincent Hanquez wrote:
> 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.
>