2011/6/12 Charles Lepple <clep...@gmail.com>
On Jun 12, 2011, at 12:48 PM, Arnaud Quette wrote: 2011/6/12 Charles Lepple <clep...@gmail.com> On Jun 11, 2011, at 3:53 PM, Arnaud Quette wrote: * jNUT Java binding the exact content of this task is still to be defined, but this should include native client access and NSS support, the following will be considered with a lower priority: - device discovery (JNI using libnut-scanner), - configuration (using Augeas) - mDNS discovery I'm currently checking resources staffing with Eaton I'm not a huge fan of Java to begin with, so do I. but having played with Android a year and a half ago, and having some requests more recently made me think we are still lacking a Java binding... but if I had to interface a Java tool with NUT, I wouldn't want the hassle of native bindings (i.e. JNI) unless it was absolutely necessary. Most of the NUT protocol should be easily implementable in pure Java (including SSL). indeed, native client access (ie implement the ascii NUT protocol in Java) is easy enough to be implemented directly (as we have in Python, Nagios plugin, ...) Ah, I think we're saying the same thing. IIRC "native" in terms of Java is the underlying processor/OS, and I think you are describing a "pure Java" implementation. indeed, so let's go for native ;-) cheers, Arno Hi all, In general: 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 ( http://swig.org/ <http://swig.org/> ). Two linked benefits can be gained from such approach : 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. 2- When you augment the API (like adding a method), all languages benefit of it with least effort (just running again the generation tool). In java specific wrapper: 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. In my developer point of view: I think it is more interesting for a developper to implement a high-level API than a simple communication protocol rewrite. I think also it is more valuable at long term for the nut project. My two cents. BR, Emilien --------------------------------------------------------------------------
_______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev