[Nut-upsdev] upsclient high level API and Java wrapping

[EmilienKia at Eaton.com]

This mail is a reply to mails from Charles Lepple and Petr Kubánek dated from july 7 with the same topic.

> From: Charles Lepple
> 
> "One thing with SWIG (and other binding systems) is that it is not  
> easy to handle errors gracefully. I can't count how many times I got  
> segmentation violation errors calling well-tested C code from Python  
> via SWIG.
> 
> I tried using ctypes, which doesn't require any recompilation of the  
> target library, but it has similar problems.

I am surprised. I follow wxWidgets open source project for a while, their python wrapping is done with SWIG and they do not have so many problems with that.
Note I have not used SWIG for python (nor python itself) personnally, so perhaps I missed something.

> The big advantage to SWIG is supposed to be that you can generate  
> bindings to many languages once you set things up, but in reality,  
> each language has its nuances for passing things by 
> reference, and so  
> each set of bindings has slightly different semantics.

I never say that SWIG will generate all bindings magically without any specific code.
The experience I had with SWIG was with Java and Lua on separated projects. In theses cases, once some specific code was set (mostly typemapping), adding methods and objects was not so problematic.

> From: Petr Kubánek
>
> I believe pure Java implementation is doable and will bring more
> benefits then hard-to-build generic Swig implementation.
>
> From: Charles Lepple
>
> Since our network protocol is so simple, we may want to stick 
> to that  
> for access from other languages. (SWIG and ctypes make sense for  
> libraries like libusb and libhid where you cannot otherwise 
> access the  
> device from the target language.)"

> I think this still applies. The bulk of the NUT logic is in the  
> drivers, with a little less in the server and clients. We're not  
> talking about wrapping the drivers or server, and very little 
> logic is  
> actually in the upsclient library. And the code in the upsclient  
> library (or a C++ library which wraps the upsclient functionality in  
> object-oriented-ness) can probably be recreated in another language  
> with less effort than it would take to write the SWIG bindings.

I know the upsclient protocol is sipmle and the java wrapping is easily doable, including SSL features. But the target of jNUT is greater than just upsclient and include nut-scanner (dev in progress) and nut-conf (augeas). Actually nut-scanner and nut-conf are libraries or simple executables over these libraries. Calling scanner functions can be done with a wrapper (like SWIG) or with an interprocess method (socket, pipes, dbus, slave process cli ...) talking to a scanner process.

> Picking on the Java bindings for a minute, the build procedure for a  
> JAR file with native code (e.g. x86, not Java bytecode) is more  
> complex than building a JAR with Pure Java code, and the resulting  
> library is non-portable.

It is true, but the complexity is not so high.

About not portable distribution, there are three problems:
1- on a package based platform (like Linuxes), nothing prevent to have plateform specific .jar with dedicated dynamic library, one per distribution per architecture.
2- on other platforms (like Windows), we have 2 solutions:
  a- distribute dedicated .jar with one plateform-specific dynamic library (probably too many)
  b- distribute .jar with many dynamic libraries (one for 32 bits, one for 64b ...) and let java choose the good one at run time
3- distribute a .jar with *all* dynamic libraries and let java choosing which one is the correct one.
Solutions 2b and 3 can probably be done with a well configured integration and build solution or with cross-compilation.

> For Perl and Python, the situation seems even more silly to me - the  
> current Perl and Python bindings don't require any compilation  
> (besides the optional bytecode step for Python).

I understand the point to not have anything to compile.

> I agree that there is value to a consistent API across the various  
> language bindings, but I don't know that SWIG is the way to go about  
> doing it.

It is not *the*, it is one.

> libhid had a pretty basic C API, but due to some arguments being  
> passed by reference, the resulting SWIG configuration was pretty ugly:
> 
> http://boxster.ghz.cc/projects/libhid/browser/trunk/swig/hid.i
> 
> All in all, maybe it's not a compelling argument against 
> SWIG, but be  
> prepared to make major changes to the new C/C++ API to accommodate  
> various languages and their quirks.

I am sure if we use SWIG, we will have some modifications for each target languages.

> Also be forewarned that I can be a 
> merciless style critic of C++ (note that we don't have any in NUT at  
> the moment)...

No problem ;)

Best regards

Emilien KIA
Software Engineer
Open Source Team
Eaton's Electrical Group PQCO/DPQD

--------------------------------------------------------------------------