<div class="gmail_quote"><div>Hi Emilien,<br><br>I've had a few neurons spinning on this thread, resurrecting an old discussion with Charles...<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">

<div><font face="Arial" size="2">
<div align="left"><span><font color="#0000ff" face="Arial" size="2">In general:</font></span></div>
<div align="left"><span><font color="#0000ff" face="Arial" size="2">As the current client API is a little too low level to be interesting 
to be wrapped to Java (and others), is there more interesting to develop a 
higher level API in C (like in Python) and to wrap it many languages (java but 
not only: python, perl and many others can be targeted) with a tool like 
SWIG ( <a href="http://swig.org/" target="_blank"><font face="Times New Roman" size="3">http://swig.org/</font></a> ).</font></span></div>
<div align="left"><span><font color="#0000ff" face="Arial" size="2">Two linked benefits can be gained from such approach 
:</font></span></div>
<div align="left"><span><font color="#0000ff" face="Arial" size="2">1- A common API can be distributed over all languages and rely on an 
unique implementation, which make them more visible and clear than many rewrites 
in each languages.</font></span></div>
<div align="left"><span><font color="#0000ff" face="Arial" size="2">2- When you augment the API (like adding a method), all languages 
benefit of it with least effort (just running again the generation 
tool).</font></span></div>
<div align="left"><span></span> </div>
<div align="left"><span><font color="#0000ff" face="Arial" size="2">In java specific wrapper:</font></span></div>
<div align="left"><span><font color="#0000ff" face="Arial" size="2">In term of distribution : platforms which provide package 
management can easily resolve dependancies between wrapped client pack and 
"native" one; on other plateforms (like windows) project can build and 
provide a "big" stand-alone jar with "native" client build for all 
plateforms (Windows x86/x64, Linux on many plateforms and so on...) or dedicated 
"light" jars for many plateforms (windows/linux, x86/x64/arm ...). This can 
probably be provided automatically with smart commands on 
buildbot.</font></span></div>
<div align="left"><span></span> </div>
<div align="left"><span><font color="#0000ff" face="Arial" size="2">In my developer point of view:</font></span></div>
<div align="left"><span><font color="#0000ff" face="Arial" size="2">I think it is more interesting for a developper to implement a 
high-level API than a simple communication protocol rewrite.</font></span></div>
<div align="left"><span><font color="#0000ff" face="Arial" size="2">I think also it is more valuable at long term for the nut 
project.</font></span></div></font></div></blockquote><div><br>from a QA standpoint, this is fully valid and relevant: having 1 implementation (ie the main C one) that serves to generate the language binding is totally in the mood of the USB helpers, AsciiDoc rewrite, ...<br>

<br>this would moreover help the current move with the scanner, and the upcoming for the configuration:<br>having these 3 libs (libupsclient, libnut-scanner and libnut-config) providing the base services, and allowing to generate the bindings for Python, Perl, Java and whatever other language that is not yet supported, is a very good approach!<br>
</div></div><br>the only issue for now is that libupsclient is still too low level.<br>for this project to be useful, we have to consider the whole needs, and the API provided.<br><br>Any thoughts?<br><br>cheers,<br>Arnaud<br>
-- <br>Linux / Unix Expert R&D - Eaton - <a href="http://powerquality.eaton.com" target="_blank">http://powerquality.eaton.com</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/" target="_blank">http://www.networkupstools.org/</a><br>

Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.free.fr/" target="_blank">http://arnaud.quette.free.fr/</a><br><br>