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

[Charles Lepple]

On Jul 6, 2011, at 5:58 AM, <EmilienKia at Eaton.com> wrote:

> Hi all,
>
> on proposal by Arnaud Quette and sponsored by Eaton, I will work on  
> a port on Java of client, discovery and config API.
>
> As I have already suggested (mail of 2011-06-14 of this ml), instead  
> of developping another port of nut protocol, I suggest to develop a  
> higher level API in C/C++ uppon existing upsclient, inspirated by  
> existing C-based tools and python and perl rewrites.
> The second goal is to release a convergent high-level API which can  
> be easily wrapped (via SWIG ?) in Java and other languages, and  
> perhaps make an uniform API for all wrappers (including perl and  
> python).

I found some old email threads with Arnaud that didn't end up on nut- 
upsdev for some reason. Here were my thoughts from 2008:

- - -

"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.

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.

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.

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.

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 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.

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. 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)...