On Jul 6, 2011, at 5:58 AM, <[email protected]> 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)...
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
