[Nut-upsdev] upsclient high level API and Java wrapping
EmilienKia at Eaton.com
EmilienKia at Eaton.com
Thu Jul 7 14:06:16 UTC 2011
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:
> 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 ;)
Open Source Team
Eaton's Electrical Group PQCO/DPQD
More information about the Nut-upsdev