Nut upsdev - Jul 2011 - upsclient high level API and Java wrapping

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 will precise my ideas in a future mail, but if anyone want to talk about its
point of view or needs.
 
Best regards,

Emilien KIA
Software Engineer

Team Open Source
Engineering Software & Connectivity
Eaton's Electrical Group PQCO/DPQD
Immeuble Viseo - B?timent A
110, rue Blaise Pascal
38330 Montbonnot St Martin
FRANCE
tel: +33(0)4 7600 6620
emilienkia at eaton.com
www.eaton.com <http://www.eaton.com/> 

 

 

 

--------------------------------------------------------------------------
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? enlev?e...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110706/a8e4fdee/attachment-0001.html>
-------------- section suivante --------------
A non-text attachment was scrubbed...
Name: att40f01.jpg
Type: image/jpeg
Size: 27774 bytes
Desc: att40f01.jpg
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110706/a8e4fdee/attachment-0001.jpg>

Dear developers, contributors and integrators,

2011/7/6 <EmilienKia at eaton.com>
> **
>
> 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 will precise my ideas in a future mail, but if anyone want to talk about
> its point of view or needs.
>
> Best regards,
>
> *Emilien** KIA*
> Software Engineer
>
> Team Open Source
> Engineering Software & Connectivity
> Eaton's Electrical Group PQCO/DPQD
> Immeuble Viseo - B?timent A
> 110, rue Blaise Pascal
> 38330 Montbonnot St Martin
> FRANCE
> tel: +33(0)4 7600 6620
> emilienkia at eaton.com
> www.eaton.com******
>
as Emilien started to present above, we (Eaton) want to help filling some of
the NUT remaining lacks while improving the API / language bindings
situation.

We also want to take this opportunity to work more collaboratively with the
NUT Community, from the upstream discussion up to the implementation.

@David and Gabor: as owners of language binding, we would be more than happy
to see you participating in this effort.

And more generally, if you have comments, ideas or needs, please send in or
jump into the thread.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110706/13f1d451/attachment.html>

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

Hi,

I fully agree with arguments about not using SWIG. I was using it back
in ~200[12] to work with CCD camera from Python, and it was horrible
mess. I later decided to rewrite full project to C++ and never thing any
good about Swig. Have another encounter with it around 2005 in another
CCD driver, provided with manufacturer, and I am really happy I was able
to get rid of Swig dependency.

I believe pure Java implementation is doable and will bring more
benefits then hard-to-build generic Swig implementation.

Petr
http://rts2.org

Hi,
> @David and Gabor: as owners of language binding, we would be more than
> happy to see you participating in this effort.
>
> And more generally, if you have comments, ideas or needs, please send in
> or jump into the thread.
I was not member of the nut-upsdev mailing list and then was not aware 
of that
discussion.

I will subscribe to it and follow this effort if needed.

Regards.